Secure firmware transfer from a server to a primary platform

ABSTRACT

A device can (i) operate a primary platform (PP) within a tamper resistant element (TRE) and (ii) receive encrypted firmware images for operating within the primary platform. The TRE can store in nonvolatile memory of the TRE (i) a PP static private key (SK-static.PP), (ii) a server public key (PK.IDS 1 ), and (iii) a set of cryptographic parameters. The TRE can generate a one-time PM key pair of SK-OT 1 .PP and PK-OT 1 .PP and send the public key PK-OT 1 .PP to a server. The TRE can receive a one-time public key from the server comprising PK-OT 1 .IDS 1 . The TRE can derive a ciphering key using an elliptic curve Diffie Hellman key exchange and the SK-static.PP, SK-OT 1 .PP, PK.IDS 1 , and PK-OT 1 .IDS 1  keys. The TRE can decrypt the encrypted firmware using the derived ciphering key. The primary platform can comprise a smart secure platform (SSP) and the decrypted firmware can comprise a virtualized image for the primary platform.

CROSS-REFERENCE TO RELATED APPLICATION

This U.S. non-provisional application claims the benefit of the filingdate of U.S. Provisional Patent Application Ser. No. 62/767,585, filedNov. 15, 2018, which is hereby incorporated by reference in itsentirety.

BACKGROUND Technical Field

The present systems and methods relate to securely transferring firmwareto a primary platform from a server, and more particularly to conductingan Elliptic Curve Diffie Hellman key exchange (ECDH) in the primaryplatform and the server in order to (i) encrypt firmware and (ii)transfer the encrypted firmware over a communications channel withinsecure elements.

Description of Related Art

The commercial development and deployment of secure processingenvironments within microprocessors and tamper resistant elements (TRE)can increase security of computing devices such as mobile phones andnetworked sensors for the “Internet of Things”. A secure processingenvironment or TRE can enable a device to securely record cryptographickeys and conduct cryptographic operations such as key exchanges, keyderivation, and also digital signatures in an a computing environmentthat is isolated from other electrical components within the device thatmay not be secure. Examples available today include an embeddedsubscriber identity module (embedded SIM), which is also known as anembedded universal integrated circuit card (eUICC), a traditional SIMcard, a secure enclave within a “system on a chip”, a trusted executionenvironment (TEE), and other examples are available as well. A commoncomputing architecture includes a processor with multiple cores, where asecure processing core is isolated from the other cores, and the secureprocessing core can read cryptographic keys and conduct cryptographicoperations. Other possibilities exist as well, including “switching” ageneric processor between an insecure mode to a secure mode.

As the number of transistors and memory cells available for a givensurface area of silicon continues to grow, the computational power forsecure processing environments continues to increase. Some secureprocessing environments can operate as a host computing environment andprovide the functionality of a virtual machine for different firmwareimages, such that each firmware image can operate as separate computingenvironments within the secure processing environment. As one example,secure processing environments can now enable a TRE to operate as aprimary platform for hosting potentially a variety of different firmwareimages, where each of the firmware images can support a differentapplication. As one example, a secure processing environment couldoperate a Java™ virtual machine, and different firmware images couldcomprise different Java applets or Java-based applications. Each Javaapplet could comprise different images for the Java virtual machine.Other possibilities exist as well for a secure processing environment tooperate as a primary platform for hosting images, and the images mayalso be referred to as a firmware image.

A primary platform both (i) operating within a secure processingenvironment and (ii) using firmware images can support a variety ofuseful applications for a computing device. The operation of an exampleprimary platform can perform functions outlined in the GSM Association(GSMA) technical document “iUICC POC Group Primary Platformrequirements”, Release 1.0 dated May 17, 2017, which is herebyincorporated by reference in its entirety (“GSMA PP Requirements”).Example applications supported by a primary platform using firmwareimages are identified in Section 3, “Use Cases” and include firmware foran embedded SIM, a traditional universal integrated circuit card (UICC),mobile payments, secure bootstrapping, digital rights management, useridentification such as a drivers license, secure access to homeautomation, a virtual automobile key, and other applications areidentified as well.

Further the European Telecommunications Standards Institute (ETSI) hasbegun developing standards for a “Secure Primary Platform” (SSP) as partof the development of 5G standards, and an SSP could operate as aprimary platform as well. As of November, 2018, the draft standards foran SSP are not available for public review, but will likely supportapplications similar to those contemplated in the GSMA PP requirementsdocument. In addition, the industry association Global Platform is alsodeveloping standards for operating a primary platform in order tosupport a variety of applications. As the standards for operating aprimary platform or a secure primary platform (SSP) continue to evolve,new features or the use of new cryptographic algorithms or steps may beintroduced. These new features and/or cryptographic steps may requirenew firmware for the primary platform in order to support new or updatedversions of the standards. A need exists in the art for a primaryplatform to securely receive updated firmware in order to supportcurrently evolving standards and features for the operation of a primaryplatform or SSP and supported applications.

Secure operation of a primary platform or an SSP for each of the abovestandards depends on the secure delivery of firmware from a server tothe primary platform. Different firmware may be required by a primaryplatform in order to support each of the above example applications.Further, over time new features may be added to the applications, whichwould also likely require a firmware update. The GSMA PP Requirementsdocument provides an overview of a proposed solution in FIG. 7 on page25. Note that the GSMA PP requirements document does not suggestnecessary and secure steps for how the firmware encryption keys (or “SSDkeys container”) can be encrypted. Secure encryption and also anauthenticated delivery of firmware to a primary platform is asignificant technical challenge, since the computing device may includeinsecure components, such as a generic processor and a generic operatingsystem. The insecure device can conduct many of the steps forcommunicating between (i) a server that sources the firmware and (ii)the primary platform. As one example, the computing device couldcomprise a mobile phone or “smartphone” based on Android or IOS orsimilar operating systems and could also either (i) operate with“malware” that is unknown to a user or a network or (ii) could comprisea “rooted” mobile phone that is under the control of hackers. A needexists in the art for the secure and authenticated encryption offirmware for a primary platform, such that a primary platform cansubsequently securely decrypt the firmware and also authenticate thefirmware is from a trusted source.

A primary platform operating in a tamper resistant element can be aresource constrained computing environment, compared to a traditionalcomputing environment of a mobile phone or a personal computer. Thisresource constrained environment can create significant challenges forauthentication of the source of a firmware image. As one example, aprimary platform may have no direct access to the Internet, but rathermust communicate through the insecure mobile phone or computing devicein order to send and receive data with a server, including updatedfirmware for the primary platform. The primary platform may not haveresources to operate a full transport layer security (TLS) stack. Theprimary platform may not readily be able to (i) use and obtain a fullchain of X.509v3 certificates and also (ii) verify a full chain ofcertificate authority certificates in order to validate a signature froman IDS server.

In addition, the proper and full implementation of certificaterevocation lists may not be feasible for the primary platform, since theprimary platform (i) cannot directly contact the repository of acertificate revocation list and (ii) depends on an insecure mobile phoneor computing device to reach a certificate revocation list. In addition,although the use of elliptic curve cryptography (ECC) may be stronglypreferred for a primary platform due both (i) limited computationresources, and (ii) the increased efficiency of ECC-based algorithms,elliptic curve digital signature algorithms also have challenges, wherethe reuse of a value k for two different signatures can reveal theprivate key. An insecure mobile phone or computing device operating aprimary platform could try to force the reuse of a value K and thusexpose a private key (either recorded at the server or in the primaryplatform). Consequently, a need exists in the art for a primary platformto receive a firmware image using an authenticated encryption keyexchange, such that a successful encryption key exchange alsoauthenticates a server providing the image.

An important objective for secure firmware download for a primaryplatform is also to obtain forward secrecy. In this manner, if a privatekey is compromised then only the subset of historical data encryptedusing the compromised private key is subject to decryption or attemptedreplay by third parties, and other communications using a differentprivate key can remain secured. An authenticated exchange can beconducted using at least two static PM key pairs (e.g. not an ephemeralkey exchange with ephemeral PM keys), but without the benefits offorward secrecy. The use of authenticated key exchanges (but withoutephemeral or one-time PM keys) for a primary platform and a server canincrease security risks over time, where repeated use of a one static PMkey pair (such a for a server private key used to communicatedpotentially with millions of devices over time) is subject tocryptographic analysis and “leakage” of equivalent bits of security overtime. A need exists in the art where both the primary platform and theserver can conduct an authenticated exchange and also obtain thebenefits of forward secrecy from including one-time PM keys in the keyexchange in order to obtain the benefits of forward secrecy.

Addressing forward secrecy can create additional problems that need tobe solved for a primary platform to securely receive firmware from aserver. The addition of ephemeral or one-time PM keys in cryptographicoperations in order to obtain forward secrecy risks attacks fromspecifically chosen ephemeral or one-time PM public keys. For example, asignificant compromise for many Bluetooth implementations was recentlyrevealed, where ephemeral public keys received for cryptographicoperations such as key exchanges could be either (i) not on an ECC curveor (ii) specifically selected to expose information about the staticprivate key. A need exists in the art for securely including one-time PMkeys in a an authenticated key exchange used by a server and a primaryplatform.

Although the GSMA PP Requirements document outlines requirements andconventional technology for the use a primary platform and firmware forimages operating on the primary platform, the GSMA PP Requirementsdocument does not suggest or teach the use of specific PM key pairs orcryptographic algorithms to use with the PM key pairs. Further, there isno teaching for how a public key for the IDS server could be securelyreceived by a primary platform. The receipt of a server public keycertificate by a resource constrained primary platform may be difficultto verify, since proper verification may require access to a full chainof certificates, and the primary platform may not have access to a fullchain of certificates, as described above. A need exists in the art fora primary platform to securely record a server public key used in a keyexchange, while using forward secrecy, in order to conduct a keyexchange in an authenticated manner. A need exists in the art for theprimary platform to use a resulting derived symmetric ciphering key fromthe key exchange in order to decrypt ciphertext firmware. A need existsin the art for a primary platform to achieve the security goals in theunique environment where a primary platform can be resource constrainedand also operate within a potentially insecure device.

Many other examples exist as well for needs in the art for a primaryplatform to securely receive firmware from a server, and the above areexamples are just a few and intended to be illustrative instead oflimiting.

SUMMARY

Methods and systems are provided for a primary platform to securelyreceive firmware from a server. The primary platform (PP) can operatewithin a tamper resistant element (TRE) and comprise a secure processingenvironment operating within a computing device. The primary platformcan comprise a secure enclave, a secure element, a trusted executionenvironment (TEE), or a “Smart Secure Platform” as specified by ETSIstandards. The computing device can comprise a mobile phone, wirelessdevice, personal computer, laptop, or a networked transducer for the“Internet of Things”. The device can (i) include insecure componentssuch as a general processor and a general operating system and (ii)communicate with the primary platform using a device driver such as aprimary boot loader (PBL) agent.

The device can connect with an internet protocol based network such asthe public Internet in order to establish a secure session with aserver. The server can comprise an image delivery server (IDS) andreceive a ciphertext firmware and a firmware key from an image maker,where the ciphertext firmware is encrypted with the firmware key. Theserver can comprise a computer with a network interface to communicatewith the device via the IP network. The server can record and operate aserver database. The device can be one of a plurality of differentdevices communicating with the server. The server can operate adatabase, where the database records at least identities for a pluralityof primary platforms and associated primary platform public keys. Thedatabase could also record a set of cryptographic parameters associatedwith the primary platform public keys. The server can record at leastone PM key pair comprising a server static public key and a serverstatic private key compatible with the set of cryptographic parameters.The server can also use a set of IDS one-time PM keys, which could bederived using a random number generator, cryptographic algorithms, andthe set of cryptographic parameters.

In exemplary embodiments an image maker can create a firmware image forthe primary platform. The firmware image can support the primaryplatform operating with an application, such as, but not limited to, aneUICC, a “Smart Secure Platform”, secure identification of the deviceusing the primary platform, and other possibilities exist as well forsupported applications. The image maker can create the firmware imagefor a plurality of different primary platforms. The image maker canderive a symmetric ciphering key and encrypt the firmware image with thesymmetric ciphering key in order to create a ciphertext firmware. Theciphertext firmware and the symmetric ciphering key can comprise anunbound image, which could be subsequently used by the server with aplurality of different primary platforms, after subsequent cryptographicoperations by the server with different primary platforms.

The primary platform and the server can record and operate a set ofcompatible values and cryptographic algorithms for an elliptic curveDiffie Hellman (ECDH) key exchange algorithm, a symmetric cipheringalgorithm, and a set of cryptographic parameters. Before distribution toan end user of the computing device, a TRE manufacturer could record aset of data in nonvolatile memory for the TRE. In addition to a PP bootfirmware and PP boot configuration for the PP, the data recorded indevice before distribution could include (i) a server static public key,(ii) a primary platform static private key, (iii) a set of cryptographicparameters associated with the static public keys, and (v) a primaryplatform identity for the TRE. For a first exemplary embodiment, theserver static public key can be unique for the TRE not shared with otherTRE. For a second exemplary embodiment, the server static public key canbe shared across a set of different TRE and thus the server staticpublic key would not be uniquely recorded in an individual TRE, but theserver static public key could be recorded in a set of TRE.

After boot and startup of both the device and the TRE operating theprimary platform, the device can use a primary boot loader (PBL) agentas a driver to communicate with the primary platform. The device can usethe PBL agent to obtain (i) a firmware status, (ii) the primary platformidentity, and (iii) a set of cryptographic parameters for the primaryplatform private key. The firmware status can comprise a list ofparameters associated with any firmware image recorded or stored by theprimary platform, including a version number for either a storedfirmware image or a version number for PP boot firmware. In exemplaryembodiments, the set of cryptographic parameters at least specifies aspecific ECC curve for the primary platform private key. The device canestablish a secure session with the server and send a first messagethrough the secure session comprising: (i) a firmware status, (ii) theprimary platform identity, and (iii) a set of cryptographic parametersfor the primary platform private key.

The server can receive the first message and process the data. Theserver can use the received primary platform identity to query thedatabase for information pertaining to the primary platform, such as aPP boot firmware version number and a PP static public key. The servercan use the firmware status to determine if a new, updated firmware isavailable for the primary platform. Upon determining that the use of anew or updated firmware image by the primary platform is desirable orpossible, the server can send the image maker a second message, wherethe second message queries the image maker for the new or updatedfirmware image. The server can receive the unbound image from the imagemaker through a secure session, where the unbound image can comprise aplaintext firmware key and the ciphertext firmware.

The server can derive a one-time PM key pair that is compatible with theset of cryptographic parameters, where the one-time PM key paircomprises a server one-time public key and a server one-time privatekey. Although described as “one-time” PM keys, the derived keys couldcomprise ephemeral or protocol keys, and in exemplary embodiments thekeys are used one-time with a specific primary platform, although theone-time PM key pair could also be used with different primaryplatforms. The server can calculate a secure hash value over the serverstatic public key and send the secure hash value of the server staticpublic key to the device through the secure session in a third message.The secure hash algorithm, such as, but not limited to, a SHA-2algorithm, could be specified in the received set of cryptographicparameters from the first message.

The device can forward the secure hash over the server static public keyto the primary platform through the PBL agent. The primary platformcould record a plurality of different server public keys, such as beingrecorded during a manufacturing step for the TRE. The primary platformcan calculate a secure hash over each of the recorded server publickeys. The primary platform can select a server public key from theplurality of recorded server public keys by finding and calculating asecure hash value that matches the hash value received in the thirdmessage. The primary platform can select or derive a PP one-time PM keypair using the set of cryptographic parameters, where the one-time PMkey pair can comprise a PP one-time public key and a PP one-time privatekey. The primary platform can also generate a random number using ahardware random number generator. The primary platform can respond tothe PBL agent with the selected or derived PP one-time public key and asecure hash value over the PP static public key and the generated randomnumber. For some exemplary embodiments, although a server is describedas sending a hash value over a server static public key and a primaryplatform is described a sending a hash value over the primary platformstatic public key, each node could also alternatively send the publickey without the use of a hash algorithm over the public key.

The device can then send the server a fourth message through the securesession with (i) the secure hash value over the PP static public key and(ii) the PP one-time public key and (iii) the random number. The servercan receive the fourth message and conduct a key validation step overthe PP one-time public key, such as confirming the PP one-time publickey is on the ECC curve specified by the set of cryptographicparameters. The server can confirm the received hash value over the PPstatic public key matches a calculated hash value over the PP staticpublic key recorded in the database for the PP identity. The server canselect or derive a server one-time PM key pair using the set ofcryptographic parameters. The server one-time PM key pair can comprise aserver one-time public key and a server one-time private key.

The server can conduct a key exchange step using at least the (i) the PPstatic public key selected using the fourth message, (ii) the PPone-time public key from the fourth message, (iii) the server staticprivate key, (iv) the server one-time private key, and (v) the set ofcryptographic parameters. The key exchange can comprise an ECDH keyexchange and use an ECDH key exchange algorithm. The output of an ECDHkey exchange can comprise a mutually derived share secret. The mutuallyderived shared secret can be input into a key derivation function (KDF)in order to derive a mutually derived symmetric ciphering key and alsooptionally a message authentication code (MAC) key.

The server can use the mutually derived symmetric ciphering key toencrypt the firmware key and the random number received in the fourthmessage, in order to obtain or store a ciphertext firmware key. Theciphertext firmware key can comprise (i) an encrypted plaintext firmwarekey and (ii) the encrypted random number. The collection of (i) theserver one-time public key, (ii) the ciphertext firmware key, and (iii)the ciphertext firmware can comprise a bound image for the primaryplatform. In this manner, (A) a bound image can comprise an image thatis specifically formatted and structured for the primary platform and(B) a different primary platform would not feasibly be able to readplaintext firmware data from a bound image. The server can send thedevice the bound image through the secure session. The device can usethe PBL agent to transfer to the bound image to the primary platform.

The primary platform can receive the bound image and read the plaintextvalue for the server one-time public key. The primary platform canconduct a key validation step over the server one-time public key,including verifying the server one-time public key is a point on the ECCcurve from the cryptographic parameters and also that the serverone-time public key is not reused. The primary platform can conduct akey exchange step using at least the (i) the selected server staticpublic key, (ii) the server one-time public key from the bound image,(iii) the PP static private key, (iv) the PP one-time private key, and(v) the set of cryptographic parameters. The key exchange can comprisean ECDH key exchange and use an ECDH key exchange algorithm equivalentto the algorithm used by the server. The output of an ECDH key exchangecan comprise a mutually derived share secret. The mutually derivedshared secret can be input into a key derivation function (KDF) in orderto derive a mutually derived symmetric ciphering key and also optionallya message authentication code (MAC) key.

The primary platform can use the mutually derived symmetric cipheringkey to conduct a first decryption step. The first decryption step withthe mutually derived symmetric ciphering key can convert the ciphertextfirmware key from the bound image into a plaintext firmware key and alsothe plaintext random number. The primary platform can verify that thedecrypted plaintext random number is equal to the random numbergenerated by the primary platform. Successful decryption of theciphertext firmware key and also verifying the decrypted random numberis equal to the random number sent by the primary platform can comprisean authentication of the server. In other words, only a server holdingthe server static private key corresponding to the server public keyrecorded by the primary platform would feasibly be able to encrypt theciphertext firmware key and random number, where the primary platformuses the server static public key to decrypt the ciphertext firmware keyand the encrypted random number.

The primary platform can use the plaintext firmware key from the firstdecryption step to conduct a second decryption step. The seconddecryption step with the plaintext firmware key can convert theciphertext firmware from the bound image into a plaintext firmware. Theprimary platform can also use the MAC key to verify a MAC code for theciphertext firmware in order to verify data integrity for the ciphertextfirmware. The ciphertext firmware may also include an initializationvector to support block chaining and the primary platform can use theinitialization vector in the second decryption step.

The primary platform can subsequently read and load the plaintextfirmware. The primary platform can begin operating with the plaintextfirmware and send an updated firmware status to the PBL agent. Theprimary platform can use the PP boot firmware to operate the receivedfirmware. The device can forward the updated firmware status to theserver over the secure session, and the updated firmware status caninclude the equivalent of an “OK” message confirming the receivedfirmware has been properly decrypted and/or loaded and/or is operatingin the primary platform. The device can begin securely operating anapplication supported by the received firmware operating in the primaryplatform. The primary platform can use the received firmware to recordcryptographic keys and conduct cryptographic operations such as digitalsignatures using the received firmware, cryptographic keys, andcryptographic algorithms in the PP boot firmware and/or the receivedfirmware.

These as well as other aspects and advantages will become apparent tothose of ordinary skill in the art by reading the following detaileddescription, with reference where appropriate to the accompanyingdrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Various exemplary embodiments are described herein with reference to thefollowing drawings, wherein like numerals denote like entities.

FIG. 1a is a graphical illustration of an exemplary system, where adevice with a secure processing environment and a server securelytransfer encrypted firmware from the server to the secure processingenvironment;

FIG. 1b is a graphical illustration of hardware, firmware, and softwarecomponents for a device, including a tamper resistant element with aprimary platform, in accordance with exemplary embodiments;

FIG. 1c is a graphical illustration of hardware, firmware, and softwarecomponents for a device, including a tamper resistant element with aprimary platform, in accordance with exemplary embodiments;

FIG. 2a is a simplified message flow diagram illustrating an exemplarysystem with exemplary data sent and received by a device with a primaryplatform, a server, and an image maker, in order to securely transfer afirmware for the primary platform to the device, in accordance withexemplary embodiments;

FIG. 2b is a flow chart illustrating exemplary steps for conducting akey exchange using PM keys in order to derive a shared secret key, forencrypting firmware with a firmware key, and for using the derivedshared secret key to encrypt the firmware key, in accordance withexemplary embodiments;

FIG. 2c is a flow chart illustrating exemplary steps for conducting akey exchange using PM keys in order to derive a shared secret key, fordecrypting a firmware key using the derived shared secret key, and fordecrypting firmware using the decrypted firmware key, in accordance withexemplary embodiments;

FIG. 3 is a flow chart illustrating exemplary steps for conducting a keyexchange using PM keys in order to derive a shared secret key, inaccordance with exemplary embodiments; and,

FIG. 4 is an illustration of an exemplary set of cryptographicparameters, in accordance with exemplary embodiments.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS OF THE INVENTION

FIG. 1a

FIG. 1a is a graphical illustration of an exemplary system, where adevice with a secure processing environment and a server securelytransfer encrypted firmware from the server to the secure processingenvironment. The system 100 can include a device 102 and a server 103,where the nodes can establish secure sessions such as a Transport LayerSecurity (TLS) 108 session over an Internet Protocol (IP) network 107.Server 103 can comprise an image delivery server 103. Although a singleserver 103 and a single device 102 are depicted in FIG. 1a , a system100 can comprise a plurality of servers 103 and devices 102. Inaddition, although a single server 103 is depicted in FIG. 1a , theexemplary server 103 shown for system 100 can comprise either differentphysical computers such as rack-mounted servers, or different logical orvirtual servers or instances operating in a “cloud” configuration,including different computing processes which are geographicallydispersed.

Server 103 could also represent different logical “server-side”processes within a network, including different programs running on aserver that listen and communicate using different IP port numberswithin one physical server. In exemplary embodiments, server 103 canoperate using the physical electrical components similar to thosedepicted and described for a device 102 in FIG. 1b below. Sever 103 canuse electrical components with larger capacities and larger overallpower consumption, compared to the capacity and power consumption forthe equivalent electrical components in a device 102. Otherpossibilities exist as well for the physical embodiment of server 103without departing from the scope of the present disclosure.

IP network 107 could be either a Local Area Network (LAN) or a Wide AreaNetwork (WAN), or potentially a combination of both. IP network 107could include data links supporting either IEEE 802.11 (WiFi) standards.Device 102 could also utilize a variety of WAN wireless technologies tocommunicate data in a secure session 108 with server 103, including LowPower Wide Area (LPWA) technology, 3rd Generation Partnership Project(3GPP) technology such as, but not limited to, 3G, 4G Long-TermEvolution (LTE), or 4G LTE Advanced, NarrowBand-Internet of Things(NB-IoT), LTE Cat M, planned future 5G networks, and other examplesexist as well. Server 103 can connect to the IP network 107 via a wiredconnection such as, but not limited to, an Ethernet, a fiber optic, or aUniversal Serial Bus (USB) connection (not shown). IP network 107 couldalso be a public or private network supporting Internet Engineering TaskForce (IETF) standards such as, but not limited to, such as, RFC 786(User Datagram Protocol), RFC 793 (Transmission Control Protocol), andrelated protocols including IPv6 or IPv4. A public IP network 107 couldutilize globally routable IP addresses and also comprise an insecurenetwork.

Device 102 can be a computing device for sending and receiving data,including a wireless device. Device 102 can take several differentembodiments, such as a general purpose personal computer, a mobile phonebased on the Android® from Google® or the IOS operating system fromApple®, a tablet, a device with a sensor or actuator for the “Internetof Things”, a module for “machine to machine” communications, a devicethat connects to a wireless or wired Local Area Network (LAN), and otherpossibilities exist as well without departing from the scope of thepresent disclosure. Device 102 can also be a computing device accordingto GSMA technical document “iUICC POC Group Primary Platformrequirements”, Approved Release 1.0 dated May 17, 2017, which is herebyincorporated by reference in its entirety (“GSMA PP Requirements”).Device 102 can comprise a device such as that depicted in FIG. 6 on page24 of the GSMA PP Requirements. Exemplary electrical components within adevice 102 are depicted and described in FIG. 1b below. Otherpossibilities exist as well for the physical embodiment of device 102without departing from the scope of the present disclosure.

Device 102 can include a private key SK.device 102 p (or secret key), adevice certificate 102 t, a tamper resistant element 113, device memory102 s, and a primary boot loader (PBL) and PP agent 102 x. Private keySK.device 102 p can comprise a private key for device 102 correspondingto a public key within device certificate 102 t. Device certificate 102t can include a set of cryptographic parameters 104 a for thecertificate as well as (i) a digital signature from a certificateauthority for the public key corresponding to (ii) the private keySK.device 102 p. The set of cryptographic parameters in certificate 102t can specify cryptographic algorithms to use with the public key andSK.device 102 p, such as elliptic curve cryptography (ECC) name curves,key length, padding schemes, and key usage (e.g. key exchange and/ordigital signatures, digital signature algorithms, etc). Devicecertificate 102 t and SK.device 102 p can also use RSA basedcryptography as well. Private key SK.device 102 p and device certificate102 t can be used by device 102 in establishing and conducting TLSsession 108 with server 103.

Tamper resistant element (TRE) 113 can comprise a tamper resistantelement as described in the GSMA PP Requirements document. Tamperresistant element can comprise a silicon enclave within a tamperresistant chip such as a “system on chip” as depicted and described inconnection with FIG. 1b below. TRE 113 can include a primary platform(PP) 101, where a primary platform is also described in the GSMA PPRequirements document. TRE 113 could also comprise a “Smart SecurePlatform” (SSP) as described in ETSI TC SCP Meeting #81 document“SCP(17)000188”, which is hereby incorporated by reference in itsentirety. Note that draft specifications for an SSP such as “103 666-1SSP Draft Specification 0.8.0” are not publicly available and haverestricted access on the ETSI web site as of Nov. 15, 2018. Primaryplatform 101 can comprise a secure operating environment, a secureenclave, a secure element, and include a dedicated processing corewithin a processor for device 102. Primary platform 101 can also operatein a Trusted Execution Environment (TEE) within a processor for device102. Primary platform 101 can also comprise a SSP as contemplated byETSI documents and draft specifications for 5G networks. Exemplarycomponents for a TRE 113 and PP 101 for a device 102 are also depictedand described in connection with FIG. 1c below.

TRE 113 and PP 101 can support a variety of applications. TRE 113 cancomprise the physical device such as that depicted in FIG. 1a and FIG.1c below, and a primary platform 101 can comprise a secure processingenvironment operating within the TRE 113. With appropriate firmware 106,TRE 113 and PP 101 could operate as an “integrated universal integratedcircuit card” (iUICC), an “embedded universal integrated circuit card”(eUICC), a secure element for banking applications or payments frommobile phones, an radio-frequency identity (RFID) card, a securebootstrap environment for device 102, a virtual key for cars or doorlocks, an secure environment for recording an identity and secret orprivate keys for drivers licenses, passports, online or web-site access,etc. Other applications for firmware 106 operating in TRE 113 and PP 101are possible as well, without departing from the scope of the presentdisclosure. In general, cryptographic keys and cryptographic algorithmsand parameters could be stored in PP 101 in order to securely supportapplications such as device programs operating on device 102. In thismanner, an insecure device program also operating on device 102 wouldnot feasibly be able to ready the cryptographic keys or use thecryptographic algorithms stored in PP 101.

Each of the above exemplary applications can be operated by a firmware106 running within TRE 113 on PP 101. Although a single firmware 106 isdepicted and described in connection with FIG. 1a and FIG. 1c below, aTRE 113 and PP 101 can operate a plurality of different firmware 106simultaneously. Each firmware 106 can operate within a virtual machinefor a processor 113 b (in FIG. 1c ) for TRE 113 and PP 101. As oneexemplary embodiment, firmware 106 can comprise a JAVA applet running ona java virtual machine in TRE 113, where the JAVA virtual machine can berecorded in secure boot firmware 121 for TRE 113 and PP 101 (shown inFIG. 1c below). Different firmware 106 operating within TRE 113 can beisolated from each other by conventional technology for processing hostsand/or virtual machines. Other possibilities exist as well for a TRE 113and PP 101 to operate as a host for an application downloaded asfirmware 106. In summary, the overall security of an applicationoperated by TRE 113 and PP 101 can depend on securely receiving firmware106 by TRE 113 and PP 102 from a server 103.

PP 101 can include a primary platform identity PP-ID 101 i, a set ofcryptographic parameters 104, PP static keys, a set of IDS static publickeys 103 p, a set of primary platform one-time keys 101 e, primaryplatform memory 101 d, a key exchange algorithm 110 b, and firmwaredecryption libraries 112. PP-ID 101 i can comprise a string of digits oralphanumeric characters to uniquely globally identify PP 101. PP-ID 101i can allow an IDS server 103 to identify the PP 101 for receiving anencrypted firmware 106. In exemplary embodiments, PP-ID 101 i can besimilar to either (i) an integrated circuit card identity (ICCID) foundon SIM cards or (ii) an embedded universal integrated circuit card(eUICC) identity of “EID”. In exemplary embodiments, PP-ID 101 i can bewritten to hardware in PP 101 and operate as a unique, long-termidentity for PP-ID 101 i. For some exemplary embodiments, PP-ID 101 ican comprise a cryptographic hash such as an SHA-256 hash value of aprimary platform static public key PK-static.PP 101 a based on a set ofcryptographic parameters 104, which could specify a secure hashalgorithm to use over PK-static.PP 101 a. For these embodiments, thenPP-ID 101 i can also potentially comprise multiple different reasonablyunique values, depending on the hash algorithm specified incryptographic parameters 104 (e.g. a first PP-ID 101 a for a first hashalgorithm and a second PP-ID 101 a for a second hash algorithm). Otherexamples for an identity of a primary platform are possible as wellwithout departing from the scope of the present disclosure.

Cryptographic parameters 104 can specify values or settings for (i)conducting an ECDH or ECDHE key exchange, (ii) mutually deriving asymmetric ciphering key, (iii) using a symmetric ciphering algorithm,(iv) an ECC curve which could comprise a commonly used name curve, (iv)PM key lengths, etc. As contemplated herein, cryptographic parameters104 may also be referred to as parameters 104, and a detaileddescription of cryptographic parameters 104 is depicted and described inconnection with FIG. 4 below. Each of PP 101, server 103, and device 102can record at least one compatible subset of parameters within a set ofcryptographic parameters 104. A subset of cryptographic parameters 104can be referred to as a “set of cryptographic parameters 104 a”.

Parameters 104 can specify values for an elliptic curve cryptography(ECC) curve name, key length, key formatting (e.g. compressed oruncompressed), encoding rules, etc. As contemplated herein, theparameters 104 and cryptographic algorithms used with ECC PM keys and akey exchange in the present disclosure can be compatible andsubstantially conform with ECC algorithms and keys as specified in (i)the IETF Request for Comments (RFC) 6090 titled “Fundamental EllipticCurve Cryptography Algorithms”, and (ii) IETF RFC 5915 titled “EllipticCurve Private Key Structure”, and also subsequent and related versionsof these standards. Other possibilities exist as well for cryptographicparameters 104 without departing from the scope of the presentdisclosure.

For use of ECC algorithms, parameters 104 can specify elliptic curvenames such as, but not limited to NIST P-256, sect283k1, sect283r1,sect409k1, sect409r1, and other possibilities exist as well. Further,elliptic curves that do not depend on curves currently specified by theNational Institute of Standards and Technology (NIST) could be utilizedas well, such as, but not limited to, Curve22519, curve448, or FourQ.Parameters 104 can specify domain parameters for elements in system 100to calculate values or numbers in a compatible manner, such as (i) acommon base point G for use with ECC PM key pairs and (ii) a definingequation for an elliptic curve. Parameters 104 can also specify settingsto use with a set of cryptographic algorithms 141 as depicted anddescribed in connection with FIG. 1c below. An exemplary set ofcryptographic parameters 104 is depicted and described in connectionwith FIG. 4 below.

PP 101 can record a set of IDS static public keys 103 p. IDS staticpublic keys 103 p can include a set of sever public keys such as anexemplary PK.IDS1 103 b, PK.IDS2, PK.IDS3, etc., where each of thepublic keys are associated with different IDS server 103 (or “server103”). Although not depicted in FIG. 1a , each public key within IDSstatic public keys 103 p can be associated with a server name oridentity in order for PP 101 to track which key is associated with whichIDS server. Server public key PK.IDS1 103 b can comprise the public keycorresponding to server private key SK.IDS1 103 a, where server privatekey SK.IDS1 103 a is recorded by a server 103. IDS static public keys103 p can also each be associated with different sets of cryptographicparameters 104 a, such as PK.IDS1 103 b using a first set ofcryptographic parameters 104 a, and PK.IDS2 using a second set ofcryptographic parameters 104 a, etc. Or, different keys within IDSstatic public keys 103 p could use the same set of cryptographicparameters 104 a.

A PP 101 can record a plurality of different network static public keysPK.IDS1 103 b in a set of IDS static public keys 103 p. Different keys103 b in a table or dataset comprising keys 103 p could be associatedwith different networks and servers 103 that PP 101 communicates withover time in order to receive firmware 106. Or a first key 103 b couldbe used with a first server, and (ii) a second, different key 103 b atable of IDS static public keys 103 p could be used as a backup orfailover key for the first server, and (iii) a third key 103 b could beused with a second server. Exemplary data for a key 103 b is depictedand described in connection with FIG. 2c below. The different keys 103 bin a set of keys 103 p can be associated with network names and/orUniform Resource Locators (URLs) or domain names, such that PP 101 canselect the key 103 b based on a URL or domain name where device 103 willreceive firmware 106.

Further, although not depicted in FIG. 1a , a PP 101 could recorddifferent public keys for the same IDS 103, such as a first PK.IDS1 103b using a first set of cryptographic parameters 104 a (such as a firstnamed ECC curve), a second PK.IDS1 103 b using a second set ofcryptographic parameters 104 a (such as a second named ECC curve), etc.The public keys in a set of IDS static public keys 103 p can also berecorded in the form of a certificate similar to certificate 102 t,where each IDS static public key is signed by a certificate authority.In exemplary embodiments, public and private keys in the presentdisclosure can comprise keys for elliptic curve cryptograph (ECC). Forembodiments where key 103 b is recorded in volatile memory, device 102could obtain key 103 b in a certificate form a different server thanserver 103 before receiving firmware 106 from server 103, such as device102 obtaining key 103 b via a secure session.

Data within a set of keys 103 p could be written upon manufacturing ofTRE 113 and configuration of PP 101. Some embodiment could support therecoding of keys 103 p via upload by a manufacturer, distributor, or anowner of device 102 in a secure manner. Data within a set of keys 103 pcould be securely written through PBL and PP agent 102 x where the keyswritten are only accepted if digitally signed by a certificate authoritywhere PP 101 records a matching certificate authority public key 131(depicted and described below in FIG. 1c ), such that PP 101 couldverify the digital signature for a key in keys 103 p using thecertificate authority public key 131. For embodiments where some keys inthe set of IDS public keys 103 p are written during manufacturing, thenthe requirement for verifying a digital signature for a key 103 b by PP101 could be optionally omitted. For embodiments where keys 103 p arerecorded in nonvolatile memory in TRE 113 after manufacturing of TRE113, keys 103 p could be uploaded by a device 102 manufacturer or devicedistributor. Other possibilities exist as well for the source and securerecording of keys 103 p and at least one key 103 b without departingfrom the scope of the present disclosure.

PP 101 can record at least one static PM key pair for PP 101 comprisingprimary platform static private key SK-static.PP 101 a and a primaryplatform static public key PK-static.PP 101 b. Primary platform staticpublic key PK-static.PP 101 b could be derived from SK-static.PP 101 ausing a set of cryptographic parameters 104. Exemplary data and valuesfor the use of a secret or private key SK-static.PP 101 a and thecorresponding public key PK-static.PP 101 b are depicted and describedbelow in connection with FIGS. 2b and 2c . Although a single PP statickey pair is depicted in FIG. 1a , a PP 101 could record multiple statickey pairs, where the different key pairs are used with different sets ofcryptographic parameters 104, such as a first key pair for use with afirst set of cryptographic parameters 104 a and a second key pair foruse with a second set of cryptographic parameters 104 a. PK-static.PP101 b could also be recorded in the form of a certificate, where thepublic key PK-static.PP 101 b is signed by a certificate authority. Ascontemplated herein, certificates for public keys can be formattedaccording to the X.509v3 set of standards, as well as subsequent orrelated standards for recording and digitally signing a certificate fora public key. SK-static.PP 101 a could be recorded in PP 101 duringmanufacturing in a secure manner, such that no nodes or entities besidesPP 101 record or store or feasibly could derive or determine the valuefor SK-static.PP 101 a.

As depicted in FIG. 1a , PP 101 could also store or record a series ofone-time PM key pairs comprising PP one-time keys 101 e. One-time PMpublic keys could comprise a sequence of public keys such as a firstprimary platform one-time public key PK-OT1.PP 101 d-1 with acorresponding first primary platform one-time secret key SK-OT1.PP 101c-1, a second PK-OT1.PP 101 d-2 with a corresponding second secret keySK-OT1.PP 101 c-2, etc. The keys 101 e could be recorded during amanufacturing step, similar to PP static keys described in the paragraphabove. In other exemplary embodiments, PP 101 could internally derivethe one-time PM key pairs as ephemeral PM keys using a random numbergenerator 128 (in FIG. 1c below) and cryptographic algorithms 141 (inFIG. 1c below) and a set of cryptographic parameters 104 a. Ascontemplated herein, the use of one-time PM keys can also be referred toas an ephemeral PM key pair or a protocol PM key pair, which contrastswith a static PM key pair. In other words, a static PM key pair can berecorded and utilized over a long period of time, such as an exemplaryseveral years, while a one-time PM key pair (or ephemeral key pair orprotocol key pair) could be used either once or over a shorter period oftime such as a single time or over a few hours or days.

PP 101 can include an ECC key pair generation algorithm in cryptographicalgorithms 141 (from FIG. 1c below) and server 103 can include acompatible ECC key pair generation algorithm for the generation of IDSOne-Time Keys 103 e for server 103 as described below. A key pairgeneration algorithm can use (i) a random number generator 128 (in FIG.1c below) in order to derive the ephemeral PM private key and (ii) aselected set of cryptographic parameters 104 a in order to calculate theephemeral PM public key. In exemplary embodiments, a random number forthe ephemeral PM private key multiplies the base point G from theparameters 104 a in order to obtain the corresponding ephemeral PMpublic key. Other possibilities exist as well for PP 101 or server 103to derive an ephemeral or one-time ECC PM key pair without departingfrom the scope of the present disclosure. A key pair generationalgorithm for PP 101 can output a one-time ECC PM pair comprising publickey PK-OT1.PP 101 c-1 and corresponding private key SK-OT1.PP 101 d-1. Akey pair generation algorithm for server 103 can output a one-time ECCPM pair comprising server one-time private key SK-OT1.IDS1 103 c-1 andcorresponding server one-time public key PK-OT1.IDS1 103 d-1.

PP 101 can operate a memory 113 s for recording or storing data receivedfrom server 103 via device 102 and PBL and PP agent 102 x. Memory 113 scan comprise a volatile random access memory (RAM) or a nonvolatileflash memory based on NAND or NOR memory cells. The memory 113 s canalso comprise a persistent memory or a nonvolatile RAM (NVRAM) memory.Memory 113 s can comprise a physical memory of NAND or NOR flash memory,such that data recorded in non-volatile memory 113 s continues to berecorded when electrical power is removed from TRE 113 and PP 101. Thedata within non-volatile memory 113 s can subsequently be read and/orre-written when power is restored to TRE 113.

Non-volatile memory for memory 113 s can include occasional bit errorsdue to the nature of the physical memory, such as small memory cellsizes, but error correcting codes operating in a processor 113 b in TRE113 (in FIG. 1c below) can normally correct the errors, to less than onepart per billion during the normal, operating lifetime of TRE 113. Ascontemplated herein, error correcting codes can comprise either (i)convolution codes operating on a bit by bit basis on memory or data frommemory, such as a Veterbi decoder, or (ii) block codes, such as aHamming codes or Reed-Solomon codes. Other possibilities for thephysical structure of memory 113 s and error correcting codes exist aswell without departing from the scope of the present disclosure.Generally (i) non-volatile memory for memory 113 s includes addressesand blocks, such that binary data can be recorded and subsequently readin a nonvolatile state, and (ii) error correcting codes attempt toidentify and correct the presence of bit errors in either physicalmemory and/or data read from the physical memory.

For some exemplary preferred embodiments, a TRE 113 could use persistentmemory, known as nonvolatile RAM (NVRAM). NVRAM can use transistor gatetechnology recording binary states within memory cells when electricalpower is removed from TRE 113. NVRAM for memory 113 s in TRE 113 and forPP 101 could use a memory chip supporting the memory technologycommercially available in the NVDIMM-P specifications as of 2018 (butnot with the DIMM physical form and rather in a specified silicon areafor TRE 113 with capabilities for NVRAM technology). In exemplaryembodiments, TRE 113 and PP 101 could use persistent memory for memory113 s, and thus obtain the benefits of faster read and write times (withlower power consumption) while also having the benefits of nonvolatilestorage, such that firmware 106 could continue to be recorded in memory113 s when power is removed from TRE 113.

Firmware 106 recorded in can provide machine executable instructions fora processor in PP 101 (such as processor 113 b depicted and described inconnection with FIG. 1c ) to execute or run. Firmware 106 could comprisea collection of compiled software libraries and programming code for theoperation of TRE 113 and PP 101. Firmware 106 could comprise aJava-based applet or application, where boot firmware of PP 101establishes and operates a Java virtual machine such as, but not limitedto JamVM or HaikuVM. Other platforms for virtualization and emulation ofa computer system by PP 101 are possible as well, without departing fromthe scope of the present disclosure, where firmware 106 can be compiledor formatted to operate on PP 101 operating as a host for thevirtualized computer system. In exemplary embodiments, firmware 106 cancomprise an application where PP 101 operates as a process virtualmachine or an application virtual machine. The environment in whichfirmware 106 operates can also be referred to as a managed runtimeenvironment (MRE).

Firmware 106 can comprise compiled software or machine executableinstructions for either (i) a processor or (ii) a virtual machine in PP101, and may also be referred to herein as an “image”. In other words,although (A) firmware may traditionally refer to machine executableprogramming instructions that provides low-level or hardware controlover computing hardware, such as memory and physical interfaces, ascontemplated herein, (B) “firmware” can comprise higher level softwarewritten for a virtual machine. In addition, the computing environment ofa primary platform can require secure functions such as writing andreading cryptographic keys for a firmware 106 specially designatedprotected memory, and thus firmware 106 comprising high level softwaremay include features similar to traditional firmware. Further, firmwaremay be traditionally associated with machine executable instructionsthat are read from a read only memory, and firmware 106 comprisingsoftware that is loaded into primary platform 101 can have featuresafter loading in PP 101 that are similar to traditional firmware, suchas firmware 106 not being readily modified by an insecure processor indevice 101. In any case, although “firmware 106” is described herein asfirmware, “firmware 106” can comprise any collection of machineexecutable instructions which can be loaded and operated by primaryplatform 101. Similarly, the GSMA PP Requirements document refers to thecollection of machine executable code for a primary platform as“firmware”.

PP 101 can also include a key exchange 110 b, which could include anECDH key exchange. For an ECDH key exchange, at least one public key andat least one private key can be input along with cryptographicparameters 104 a in order to output a shared secret. The other party(such as server 103) can also input at least one private key(corresponding to the public key in the prior sentence) and at least onepublic key (corresponding to the private key in the previous sentence)in order to mutually derive the same shared secret. A summary of ECDH asa key exchange for key exchange algorithm 110 b and 110 a (in server103) is included in the Wikipedia article titled “Elliptic CurveDiffie-Hellman” from Mar. 9, 2018, which is herein incorporated byreference. An exemplary embodiment of key exchange algorithm 110 b and110 a (in server 103) could comprise a “One-Pass Diffie-Hellman, C(1, 1,ECC CDH)” algorithm as described in section 6.2.2.2 on page 81 of theNational Institute of Standards and Technology (NIST) document “NIST SP800-56A, Recommendation for Pair-Wise Key Establishment Schemes UsingDiscrete Logarithm Cryptography” from March, 2007 which is herebyincorporated by reference its entirety.

Other key exchange algorithms in NIST SP 800-56A could be utilized aswell for a key exchange algorithm 110 b and 110 a in FIG. 1a withoutdeparting from the scope of the present disclosure. Exemplarycalculations for an ECDH key exchange for a key exchange algorithm 110 aare shown below in FIG. 2b and exemplary calculations for an ECDH keyexchange for a key exchange algorithm 110 b are shown below in FIG. 2c .The output of a commonly shared secret key can be used with a keyderivation function (KDF) in order to derive a mutually shared symmetricciphering key. The mutually derived symmetric ciphering key can be usedby PP 101 for with firmware decryption 112.

PP 101 can include a firmware decryption 112, which converts aciphertext firmware 106* and a ciphertext firmware key 106 a* into aplaintext firmware 106. Exemplary details for firmware decryption 112are depicted and described in connection with FIG. 2c below. In summary,a first step 112 a can comprise a decryption step of ciphertext firmwarekey 106 a* by PP 101 using the mutually derived symmetric ciphering keyfrom key exchange 110 b. The output of a first step 112 a for firmwaredecryption 112 can comprise a plaintext firmware key 106 a. A plaintextfirmware key is contemplated herein as a designation of “106 a” and aciphertext firmware key is contemplated herein as a designation of “106a*”. A second step 112 b can comprise a decryption step of ciphertextfirmware 106* by PP 101 using the plaintext firmware key 106 a in orderto read a plaintext firmware 106. A plaintext firmware is contemplatedherein as a designation of “106” and a ciphertext firmware iscontemplated herein as a designation of “106*”. A processor in PP 101can read instructions in a plaintext firmware 106 but could not feasiblyread instructions within a ciphertext firmware 106*, and thus PP 101records and operates on a plaintext firmware 106 after a firmwaredecryption 112.

In exemplary embodiments, the ciphertext firmware 106* can comprise theencrypted firmware in FIG. 7 of the GSMA white paper, and the firmwarekey 106 a can comprise the “SSD keys container” also in FIG. 7 of theGSMA white paper. Although the use of a separate ciphertext firmware key106 a* is depicted in FIG. 1a , for some exemplary embodiments, in otherexemplary embodiments, the transmission of a separate ciphertextfirmware key 106 a* could be omitted, and PP 101 could use a firmwaredecryption step 112 and a mutually derived symmetric ciphering key fromkey exchange 110 b in order to directly decrypt ciphertext firmware 106*(and server 103 could omit the use of a ciphertext firmware key 106 a*as well). In other words, for embodiments without the transfer of aciphertext firmware key 106 a*, then (i) PP 101 and IDS 103 couldmutually derive the equivalent of firmware key 106 a* such that the key106 a* does not need to be transmitted, and (ii) ciphertext firmware106* could be encrypted with the mutually derived equivalent of firmwarekey 106 a*.

PBL and PP agent 102 x in device 102 can comprise a program or processoperating in device 102 for managing the communications with PP 101,such as reading the ciphertext firmware key 106 a* and ciphertextfirmware 106* from device nonvolatile memory 102 s and writing theciphertext firmware key 106 a* and ciphertext firmware 106* to the PP101. Note that in exemplary embodiments, PBL and PP agent 102 x couldalso write the one-time IDS public key 103 d-1 to PP 101. Device 102could obtain ciphertext firmware key 106 a* and ciphertext firmware 106*and the associated one-time IDS public key 103 d-1 from server 103 viaTLS session 108. The collection of ciphertext firmware key 106 a* andciphertext firmware 106* and IDS public key 103 d-1 can comprise a boundpackage 114. Although the use of a nonvolatile memory 102 s is depictedin FIG. 1a , a device 102 could record data from the bound package 114in a volatile memory such as RAM or also an NVRAM memory. Device memory102 s can comprise general memory for device 102 and also record otherdata for device 102 than that depicted in FIG. 1a . “PBL and PP agent102 x” may also be referred to herein as agent 102 x and agent 102 xcould manage communications between device 102 and PP 101 via electricalpads 109 a depicted in FIG. 1b . In other words, agent 102 x could sendand receive data with PP 101 for functions other than conducting primaryboot loader. For some embodiments, an agent 102 x could also be referredto as an “Open Firmware Loader” agent.

For system 100, server 103 and device 102 may establish a secure session108, which could comprise establishing a secure communications linkbetween the two servers using protocols such as TLS, IPSec, a virtualprivate network (VPN), a secure shell (SSH), or similar networking,transport, or application layer technologies in order to establishsecure communications between server 103 and device 102. Secure session108 is depicted as “TLS 108” but other methods for establishing securesessions could be used as well, including Datagram Transport LayerSecurity (DTLS). Secure session 108 can utilize certificates for server103 and/or device 102 in order to provide mutual authentication andmutual key derivation for a symmetric encryption key in secure session108. For some embodiments, the use of a certificate 102 t for device 102in secure session 108 could be omitted, and for these embodiments onlyserver 103 would be authenticated. Other possibilities exist as well forestablishing a secure session 108 between server 103 and device 102without departing from the scope of the present disclosure. Server 103can begin listening for incoming messages from a device 102 using aphysical network interface that provides connectivity to the IP network107 and server 103 can use a specific port number such as TCP port 443to listen for incoming data for secure session 108 from a device 102.

As depicted for the secure session 108 in FIG. 1a , a device 102 couldsend an identity for the primary platform comprising PP-ID 101 i as wellas public keys comprising PP static public key PK-static.PP 101 b andone-time public key PK-OT1.PP 101 d-1. Although not depicted in FIG. 1a, device 102 could also send a subset of cryptographic parameters 104 a(where the set of cryptographic parameters 104 can comprise a supersetof the subset 104 a) associated with PP 101 and PK-static.PP 101 b inorder for server 103 to determine parameters 104 a to use with aPK-static.PP 101 b. For some embodiments, server 103 could obtainPK-static.PP 101 b from other means than TLS 108 (such as from a devicemanufacturer) and for these embodiments then PP-static.PP 101 b could beomitted from the secure session 108. For other embodiments, the use of aone-time PM key pair for PP 101 could be omitted, such as a key exchange301 a in FIG. 3 below. Device 102 could obtain the data transmitted bydevice 102 in secure session 108 from PP 101 via PBL and PP agent 102 x.In the exemplary embodiments depicted in FIG. 2a below, device 102 couldalternatively send a secure hash value over PP-static.PP 101 b, andserver 103 could select the PP static public key PK-static.PP 101 bbased on the secure hash value.

As depicted in FIG. 1a , IDS server 103 can include a server private keySK-TLS.IDS 103 s, a server certificate 103 t, a database for primaryplatform units comprising PP database 103 d, a table or set of IDSstatic keys, a table or set of IDS one-time PM keys 103 e, a set ofcryptographic parameters 104, firmware key 106 a, ciphertext firmware106*, a key exchange 110 a, and a firmware key encryption 111. Ascontemplated herein, an IDS server 103 can also be referred to as a“server 103”. Server private key SK-TLS.IDS 103 s and server certificate103 t can be used in the establishment of secure session 108 with device102, such as for authenticating IDS server 103 with device 102. The PPdatabase 103 d can include data for a plurality of different primaryplatforms 101 operating in different devices 102, such as, but notlimited to, an identity for PP 101 of PP-ID 101 i and a public key ofPK-static.PP 101 b.

Other data for PP database 103 d could include the set of cryptographicparameters 104 for the PP 101, a boot or operating system version for PP101, a list of versions of current firmware 106 operating with PP 101,and other possibilities as well. IDS server 103 could use PP database103 d to determine which version of a firmware 106 or ciphertextfirmware 106* to send to which device 102 with PP 101. Although notdepicted in FIG. 1a , server 103 could also record an identity, whichcould comprise a domain name, IP address, or similar text or numericalvalue to uniquely identify server 103. For depiction of keys in FIG. 1aand subsequent Figures, the keys for server 103 are displayed as “IDS1”.A different IDS server 103 for a system 100 or system 200 below couldhave the different values of “IDS2”, etc.

The set of IDS static keys can record or store at least one static PMkey pair for server 103 comprising server static private key SK.IDS1 103a and server static public key PK.IDS1 103 b. Server static public keyPK.IDS1 103 b could be derived from SK.IDS1 103 a. PK.IDS1 103 b couldcomprise PM keys formatted and compatible with a set of cryptographicparameters 104, where each subset of cryptographic parameters 104 acould be associated with different IDS static PM keys. Exemplary dataand values for the use of a secret or private key SKIDS' 103 a and thecorresponding public key PK.IDS1 103 b are depicted and described belowin connection with FIGS. 2b and 2c . Although a single key pair isdepicted in FIG. 1a , a server 103 could record multiple key pairs,where the different key pairs are used with different sets ofcryptographic parameters 104, such as a first key pair for use with afirst set of cryptographic parameters and a second key pair for use witha second set of cryptographic parameters. PK.IDS1 103 b could also berecorded in the form of a certificate, where the public key PK.IDS1 103b is signed by a certificate authority. SK.IDS1 103 b could be recordedin server 103 during in a secure manner during a server configurationstep, such that no nodes or entities besides server 103 record or storeor feasibly could derive or determine the value for SK.IDS1 103 b.

As depicted in FIG. 1a , server 103 could also store or record a seriesof one-time PM key pairs comprising IDS one-time keys 103 e. One-time PMpublic keys could comprise a sequence of public keys such as a firstPK-OT1.IDS1 103 d-1 with a corresponding first secret key SK-OT1.IDS1103 c-1, a second PK-OT2.IDS1 103 d-2 with a corresponding second secretkey SK-OT2.IDS1 103 c-2, etc. The keys 103 e could be derived using akey pair generation algorithm and a random number generator, similar orequivalent to the key pair generation algorithm described for PPone-time keys 101 e for PP 101 above. Each of the PM key pairs orindividual public keys for PP 101 recorded in server 103 could beassociated with a set of cryptographic parameters 104. A set ofcryptographic parameters 104 was also described above for a PP 101 andalso depicted and described in more detail below in FIG. 4.

IDS server 103 could receive a ciphertext firmware 106* and a plaintextfirmware key 106 a from a secure channel with an image maker, which isalso depicted in FIG. 6 of the GSMA PP Requirements document. The imagemaker could be a different server for the processing and creation ofimages for PP 101 than a server 103. Note that IDS server 103 couldcommunicate with a plurality of different image makers, and the IDSserver 103 could select or query for an image for PP 101 using the PP-IDreceived in secure session 108 and a PP database 103 d. Otherpossibilities for the source and selection of a ciphertext firmware 106*and plaintext firmware key 106 a exist without departing from the scopeof the present disclosure. For some embodiments, IDS server 103 couldreceive and record plaintext firmware 106 and encrypt the firmware 106into ciphertext firmware 106* using a mutually derived symmetricciphering key from a key exchange 110 a. In exemplary embodiments, theciphertext firmware 106* and firmware key 106 a can be utilized with aplurality of different PP 101, and the process of encrypting thefirmware key 106 a into a ciphertext firmware key 106 a* can be uniquefor each different PP 101.

Server 103 can also include a key exchange algorithm 110 a, which couldinclude an ECDH key exchange. Key exchange algorithm 110 a in server 103can be equivalent or correspond to key algorithm 110 b in PP 101described above. For an ECDH key exchange, at least one public key andat least one private key can be input along with cryptographicparameters 104 in order to output a shared secret. The other party (suchas PP 101) can also input at least one private key (corresponding to thepublic key in the prior sentence) and at least one public key(corresponding to the private key in the previous sentence) in order tomutually derive the same shared secret. Exemplary calculations for anECDH key exchange for a key exchange algorithm 110 a are shown below inFIG. 2b . The output of a commonly shared secret key can be used with akey derivation function (KDF) in order to derive a mutually sharedsymmetric ciphering key. The mutually derived shared symmetric cipheringkey can be used with a firmware key 106 a encryption step 111. Themutually derived symmetric ciphering key can be used by PP 101 for withfirmware decryption 112. As contemplated herein, a “shared secret” canbe the same as and also referred to as a “shared secret key”.

Server 103 can include a firmware key encryption 111, which converts aplaintext firmware key 106 a into a ciphertext firmware key 106 a*,where the ciphertext firmware key 106 a* can only feasibly be decryptedby PP 101. Exemplary details for firmware key encryption 111 aredepicted and described in connection with FIG. 2b below. In summary, afirmware key encryption 111 can comprise an encryption step of plaintextfirmware key 106 a by server 103 using the mutually derived symmetricciphering key from key exchange 110 a. The output of a firmware keyencryption 111 can comprise a ciphertext firmware key 106 a*. IDS server103 can then send device 102 a bound image 114 or a bound packagecomprising the ciphertext firmware key 106 a* and the ciphertextfirmware 106*. The bound image 114 can include IDS one-time public keyPK-OT1.IDS 103 d-1 for PP 101 to use in order to derive the mutuallyderived symmetric ciphering key. Or, in some embodiments the IDSone-time public key PK-OT1.IDS 103 d-1 could be omitted from a boundimage 114 and set separately from the ciphertext firmware key 106 a* andthe ciphertext firmware 106*.

Note that the ciphertext firmware key 106 a* and the ciphertext firmware106* are sent or transmitted to device 102 within the secure session108, and thus would be “double encrypted”. The double encryption can beuseful because (i) the processor in device 102 could be untrusted orinsecure, while PP 101 could be trusted, and (ii) device 102 wouldnormally “unrap” or decrypt the encryption from secure session 108.Thus, the plaintext data read from receiving data in secure session 108can comprise ciphertext for PP 101. PP 101 can receive the bound image114 via PBL and PP agent 102 x and subsequently decrypt the data andread and load firmware 106 using a key exchange 110 b and a decryptionstep 112. In this manner, a firmware 106 can be securely delivered to PP101 through an insecure device and also an insecure network such asInternet 107. Additional details will be provided in subsequent Figuresbelow.

FIG. 1b

FIG. 1b is a graphical illustration of hardware, firmware, and softwarecomponents for a device, including a tamper resistant element with aprimary platform, in accordance with exemplary embodiments. FIG. 1b isillustrated to include many components that can be common within adevice 102, and device 102 may also operate in a wireless configurationin order to connect with a wireless network. In a wirelessconfiguration, the physical interface 102 a of device 102 may supportradio-frequency (RF) communications with networks including a wirelessnetwork via standards such as GSM, UMTS, mobile WiMax, CDMA, LTE, LTEAdvanced, 5G, and/or other mobile-network technologies. In a wirelessconfiguration, the physical interface 102 a may also provideconnectivity to local networks such as 802.11 WLAN, Bluetooth, Zigbee,or an IEEE 802.15.4 network, among other possibilities. In a wirelessconfiguration, device 102 could use a physical interface 102 a connectedwith both a wireless WAN and wireless LAN simultaneously. In a wiredconfiguration, the physical interface 102 a can provide connectivity toa wired network such as through an Ethernet connection or USBconnection.

The physical interface 102 a can include associated hardware to provideconnections to components such as radio-frequency (RF) chipsets, a poweramplifier, an antenna, cable connectors, RF filters, etc. Device drivers102 g can communicate with the physical interfaces 102 a, providinghardware access to higher-level functions on device 102. Device drivers102 g may also be embedded into hardware or combined with the physicalinterfaces. Device drivers 102 g can include a PBL and PP agent 102 x,which can be utilized by a device 102 and operating system 102 h inorder to read and write data to TRE 113, including communicating with aprimary platform 101 within TRE 113. Device 102 may preferably includean operating system 102 h to manage device drivers 102 g and hardwareresources within device 102. The operating systems described herein canalso manage other resources such as memory and may support multiplesoftware programs or software libraries operating on device 102,including applications that communicate with PP 101 through a devicedriver 102 g.

The operating system 102 h can include Internet protocol stacks such asa User Datagram Protocol (UDP) stack, Transmission Control Protocol(TCP) stack, a domain name system (DNS) stack, etc., and the operatingsystem 102 h may include timers and schedulers for managing the accessof software to hardware resources, including TRE 113. The operatingsystem shown of 102 h can be appropriate for a low-power device withlimited memory and CPU resources (compared to a server 103). Exampleoperating systems 102 h for a device 102 includes Linux, Android® fromGoogle®, IoS from Apple®, Windows® Mobile, or Open AT® from SierraWireless®. Additional example operating systems 102 h for device 102include eCos, uC/OS, LiteOs, Contiki, OpenWRT, Raspbian, and otherpossibilities exist as well without departing from the scope of thepresent disclosure.

A device program 102 i may be an application programmed in a languagesuch as, but not limited to, C, C++, Java, and/or Python, and couldprovide functionality to support M2M applications such as remotemonitoring of sensors and remote activation of actuators. A deviceprogram 102 i could also comprise an application for a mobile phone,table, personal computer, or the like. Device program 102 i could alsobe a software routine, subroutine, linked library, or software device,according to one preferred embodiment. As contemplated herein, a deviceprogram 102 i may be an application operating within a smartphone, suchas an iPhone® or Android®-based smartphone, and in this case device 102could comprise the smartphone. The application functioning as a deviceprogram 102 i could be downloaded from an “app store” associated withthe smartphone. Device program 102 i can include secure session library102 y, which can provide the functionality or “System on a Chip” (SOC)109 instructions for conducting secure session 108.

Many of the logical steps for operation of device 102 can be performedin software and hardware by various combinations of sensor 102 f,actuator 102 z, physical interface 102 a, device driver 102 g, operatingsystem 102 h, device program 102 i, and SOC 109. Note that device 102may also optionally include user interface 102 j which may include oneor more devices for receiving inputs and/or one or more devices forconveying outputs. User interfaces are known in the art for devices 102and could include a few LED lights or LCD display or OLED display, andthus user interfaces are not described in detail here. User interface102 j could comprise a touch screen if device 102 operates as asmartphone or mobile phone. As illustrated in FIG. 1b , device 102 canoptionally omit a user interface 102 j, since no user input may berequired for many M2M applications, although a user interface 102 jcould be included with device 102.

Device 102 may be a computing device or wireless device that includescomputer components for the purposes of collecting data from a sensor102 f or triggering an action by an actuator 102 y. Device 102 mayinclude a central processing unit (CPU) within SOC 109, a random accessmemory (RAM) 102 e, and a system bus 102 d that couples various systemcomponents including the random access memory 102 e to the processingunit 102 b. The system bus 102 d may be any of several types of busstructures including a memory bus or memory controller, a peripheralbus, and a local bus using any of a variety of bus architecturesincluding a data bus.

Device 102 may include a read-only memory (ROM) 102 c which can containa boot loader program. Although ROM 102 c is illustrated as “read-onlymemory”, ROM 102 c could comprise long-term memory storage chipsets orphysical units that are designed primarily for writing once and readingmany times, such as Electrically Erasable Programmable Read-Only Memory(EEPROM). As contemplated within the present disclosure, a read-onlyaddress could comprise an address within a read only memory such as aROM 102 c memory address or another hardware address for read-onlyoperations accessible via bus 102 d. Changing data recorded in a ROM 102c can require a technician have physical access to device 102, such asremoving a cover or part of an enclosure, where the technician cansubsequently connect equipment to a circuit board in device 102,including replacing ROM 102 c. ROM 102 c could also comprise anonvolatile memory, such that data is stored within ROM 102 c even if noelectrical power is provided to ROM 102 c.

Device 102 can include a SOC 109 and SOC 109 is also depicted anddescribed in connection with FIG. 1c below. SOC 109 can include TRE 113,and additional details for the operation of SOC 109 and TRE 113 isprovided in subsequent figures. Although TRE 113 is depicted in FIG. 1bas operating within SOC 109, TRE 113 could be operated within aremovable unit such as an SD card, a SIM card, etc. Or TRE 113 couldoperate within a separate soldered chip connected to bus 102 d. Anexemplary removable form factor for TRE 113 could comprise a standard SDcard, a mini SD card, a micro SD card, a mini UICC, a micro UICC, or anano UICC, and other possibilities exist as well without departing fromthe scope of the present disclosure. SOC 109 can include electricalcontacts (such as external pads 109 a depicted in FIG. 1c ) whichprovide electrical connectivity to bus 102 d.

SOC 109 can include NAND or NOR flash memory in order to record datawhen device 102 is not powered, and other nonvolatile memorytechnologies can be used in a storage unit as well without departingfrom the scope of the present disclosure. SOC 109 can be separatelymanufactured from device 102 and accessed and loaded with data beforeinsertion into device 102. SOC 109 could also operate as an “embedded”unit, such that storage unit comprises an integrated circuit soldered toa circuit board in device 102, and in these embodiments SOC 109 can befixed and not removable.

In exemplary embodiments, SOC 109 can include a TRE 113, and additionaldetails regarding the components and operation of a TRE 113 are depictedand described in additional figures below, including FIGS. 1c . Theinclusion of TRE 113 and the operation of TRE 113 with PP 101 in SOC 109can add functionality for SOC 109 that is not normally included incommercially available SOC in the market as of 2018, such as with thesecure receipt of firmware 106 as described herein. TRE 113 within SOC109 can include a processor, bus, and memory similar (but with lesspower and on a smaller scale) as the CPU 102 b, bus 102 d, and ROM 102c. TRE 113 can perform cryptographic functions using either bootfirmware or downloaded firmware 106 such as (i) internally deriving aprivate key such as PP private key 103 e in a cryptographically securemanner, (ii) recording the private key in a protected memory such thatdevice 102 or external parties cannot feasibly or cost-effectively readthe derived private key, and (ii) conducting key exchanges andencryption/decryption.

Although the exemplary environment described herein employs ROM 102 c,RAM 102 e, and nonvolatile memory (NVM) 102 s, it should be appreciatedby those skilled in the art that TRE 113 could also operate within othertypes of computer readable media which can store data that is accessibleby a device 102, such as memory cards, subscriber identity device (SIM)cards, local miniaturized hard disks, and the like, which may also beused in the exemplary operating environment without departing from thescope of the disclosure. The memory and associated hardware illustratedin FIG. 1b provide nonvolatile storage of computer-executableinstructions, data structures, program devices, device program 102 i,device drivers 102 g, and other data for computer or device 102. Notethe device 102 may include a physical data connection at the physicalinterface 102 a such as a miniaturized universal serial bus adapter,firewire, optical, or other another port and the computer executableinstructions such as device program 102 i, operating system 102 h, ordevice driver 102 g can be initially loaded into memory such as ROM 102c or NVM 102 s through the physical interface 102 a before device 102 isgiven to an end user, shipped by a manufacturer to a distributionchannel, or installed by a technician.

Further, device program 102 i, operating system 102 h, or device driver102 g can be separately loaded into NVM 102 s before or afterdistribution of device 102. In some exemplary embodiments, applicationsor programs operating within device 102 can be given limited orrestricted access to TRE 113 in order to support the applications orprograms. For example, a mobile payment application operating a deviceprogram 102 i could authenticate either device 102 or a user with keysrecorded in TRE 113 and a firmware 106. Device program 102 i couldprovide a graphical user interface (GUI) to a user through userinterface 101 j. Other possibilities exist as well for a device program102 i to operate in conjunction with keys and identities recorded in TRE113 without departing from the scope of the present disclosure.

A number of program devices may be stored in RAM 102 e, ROM 102 c, orNVM 102 s, including an operating system 102 h, device driver 102 g, anhttp client (not shown), a DNS client, and related software. TRE 113 canrecord program devices as well, where the program devices in TRE 113 maybe focused on cryptographic operations and functions conducted withinTRE 113 in support of the operation of device 102. A firmware 106depicted and described in connection with FIG. 1a and other figuresherein can comprise a program device. Program devices include routines,sub-routines, programs, objects, components, data structures, etc.,which perform particular tasks or implement particular abstract datatypes. Aspects of the present disclosure may be implemented in the formof (i) a device program 102 i which are executed by the device 102working in conjunction with (ii) firmware 106 on TRE 113 and PP 101 toauthenticate device 102 with a server using public key infrastructure.In exemplary embodiments, program devices for TRE 113 in SOC 109 caninclude cryptographic algorithms 141 as depicted and described inconnection with FIG. 1c below.

A user may enter commands and information into device 102 through anoptional user interface 102 j, such as a keypad, keyboard (possiblyminiaturized for a mobile phone form-factor), and a pointing device.Pointing devices may include a trackball, an electronic pen, or a touchscreen. A user interface 102 j may also include a display (not shown)such as a device screen. A display may also be connected to system bus102 d via an interface. The display can comprise any type of displaydevices such as a liquid crystal display (LCD), a plasma display, and anorganic light-emitting diode (OLED) display. Device 102 may also includea camera (not shown) connected to or integrated with device 102 througha physical interface 102 a, and the camera can comprise a video camerafor the device 102 to collect sensor data that includes video or images.The camera (not shown) can be a CCD (charge-coupled device) camera, aCMOS (complementary metal-oxide-semiconductor) camera, or a similardevice to collect video or camera input including QR codes. Otherarrangements could be used as well, without departing from thedisclosure.

The device 102, comprising a computer, may operate in a networkedenvironment using logical connections to one or more remote computers,such as servers. Servers communicating with device 102 can also functionas a general purpose server to provide files, programs, disk storage,remote memory, and other resources to device 102 usually through anetworked connection. Additional remote computers with which device 102communicates may include another device 102 or mobile device, an M2Mnode within a capillary network, a personal computer, other servers, aclient, a router, a network PC, a peer device, a wireless network, orother common network nodes. The servers or networks communicating withdevice 102 or a remote computer typically includes many of the elementsdescribed above relative to the device 102, including a CPU, memory, andphysical interfaces. It will be appreciated that the network connectionsshown throughout the present disclosure are exemplary and other means ofestablishing a wireless or wired communications link may be used betweenmobile devices, computers, servers, corresponding nodes, and similarcomputers. The operation of a TRE 113 within device 102 with a firmware106 can be utilized to authenticate a device 102 in each or any of theabove described networking environments.

The device program 102 i operating within device 102 illustrated in FIG.1b and communicating with TRE 113 can provide computer executableinstructions to hardware such as CPU 102 b through a system bus 102 d inorder for a device 102 to (i) transmit and receive data with a serviceprovider, (ii) monitor a sensor and/or change the state of an actuator102 y, (iii) send or receive packets with a server or network, and (iv)authenticate with a server, thus allowing the server to remotely monitoror control device 102 in an authenticated and secure manner. The deviceprogram 102 i can enable the device 102 to authenticate and communicatewith a server by recording data in memory such as RAM 102 e, where thedata can include sensor data, a destination IP address number, a packetor packet header value, an encryption or ciphering algorithm and key, adigital signature and public key, etc, where cryptographic operations orcalculations for the device program 102 i can be performed by TRE 113using firmware 106. The data recorded in RAM 102 e can be subsequentlyread by the operating system 102 h or the device driver 102 g. Theoperating system 102 h or the device driver 102 g can write the data toa physical interface 102 a using a system bus 102 d in order to use aphysical interface 102 a to send data such as a digital signature forauthentication to a server using the Internet 107. In exemplaryembodiments, the digital signature can be generated or processed in theTRE 113 using a PP 101 and firmware 106. Alternatively, the deviceprogram 102 i can write the data directly to the physical interface 102a using the system bus 102 d.

In general, digital signatures for authentication with a server can beperformed in TRE 113, where the digital signature output is transferredfrom TRE 113 to RAM 102 e before being transmitted from device 102 to aserver through the IP network 107. The data recorded in RAM 102 e suchas a digital signature can be subsequently read by the operating system102 h or the device driver 102 g. Note that device driver 102 g caninclude PBL and PP agent 102 x in order to communicate with TRE 113.Thus, PBL and PP agent 102 x can be a device driver 102 g specificallyfor TRE 113. The operating system 102 h or the device driver 102 g canwrite the data to a physical interface 102 a using a system bus 102 d inorder to use a physical interface 102 a to send data such as a digitalsignature for authentication to a server using the Internet 107.Alternatively, the device program 102 i can write the data directly tothe physical interface 102 a using the system bus 102 d. Otherpossibilities exist as well without departing from the scope of thepresent disclosure.

The device program 102 i or operating system 102 h using TRE 113 and PP101 with firmware 106 can include steps to process the data recorded inmemory such as encrypting data, selecting a destination address, orencoding sensor data acquired by (i) a sensor 102 f or (ii) through aphysical interface 102 a such as a thermocouple, shock or vibrationsensor, light sensor, or global positioning system (GPS) receiver, etc.The device 102 can use the physical interface 102 a such as a radio totransmit or send (i) the data from a sensor or (ii) a digital signaturefrom TRE 113 to a wireless network 102. For those skilled in the art,other steps are possible as well for a device program 102 i or operatingsystem 102 h to collect data from either (i) a sensor 102 f or (ii) aTRE 113 and send the data in a packet without departing from the scopeof the present disclosure.

Conversely, in order for device 102 to receive a packet or response fromserver, which could include a challenge or nonce in order toauthenticate a device 102 with the server, the physical interface 102 acan use a radio to receive the challenge or nonce from a wirelessnetwork. The challenge or nonce received from the server through thewireless network could comprise a random number or a pseudo randomstring of digits, bits, and/or characters. The received data can includeinformation from a server and may also comprise a datagram, a source IPaddress number, a packet or header value, an instruction for device 102,an acknowledgement to a packet that device 102 sent, a digitalsignature, and/or encrypted data. The operating system 102 h or devicedriver 102 g can use a system bus 102 d and CPU 102 b to record thereceived data such as a challenge or nonce from a server in memory suchas RAM 102 e, and the device program 102 i or operating system 102 h mayaccess the memory in order to process the received data and determinethe next step for the device 102 after receiving the data.

Processing the received data from a server to device 102 could includedeciphering or decrypting received data by TRE 113 with a key recordedin TRE 113, sending the challenge or nonce to the TRE 113, reading aninstruction from a server, or similar transformations of the receiveddata. The steps within the paragraph above may also describe the steps adevice program 102 i can perform in order to receive a packet. For thoseskilled in the art, other steps are possible as well for a deviceprogram 102 i or device 102 to receive a packet or challenge or noncefrom a server without departing from the scope of the presentdisclosure. A server described herein without the designation of “server103” or IDS server 103 can comprise a different server than server 103communicating with device 102 in support of an application operating asa device program 102 i.

Moreover, those skilled in the art will appreciate that the presentdisclosure may be implemented in other computer system configurations,including hand-held devices, netbooks, portable computers,multiprocessor systems, microprocessor based or programmable consumerelectronics, network personal computers, minicomputers, mainframecomputers, servers, and the like. The disclosure may also be practicedin distributed computing environments, where tasks are performed byremote processing devices that are linked through a communicationsnetwork. In a distributed computing environment, program devices may belocated in both local and remote memory storage devices. In addition,the terms “mobile node”, “mobile station”, “mobile device”, “M2Mdevice”, “M2M device”, “networked sensor”, or “industrial controller”can be used to refer to device 102 as contemplated herein.

Although not depicted in FIG. 1b , a server shown above in FIG. 1a suchas IDS server 103 and other servers as well can include equivalentinternal components as device 102 in order to operate. The server 103 inFIG. 1a could include a processor similar to CPU 102 c, with primarydifferences for the processor server being increased speed, increasedmemory cache, an increased number and size of registers, the use of a 64bits for datapath widths, integer sizes, and memory address widths, asopposed to an exemplary 32 bits for processor cores in SOC 109 or anexemplary 32 or 16 bits for a processor in TRE 113. Other possibilitiesexist as well for the size of datapath widths for a TRE 113 andprocessing core in device 102 without departing from the scope of thepresent disclosure. Similarly, RAM in a server could be a RAM similar toRAM 102 e in device 102, except the RAM in a server could have morememory cells such as supporting exemplary values greater than anexemplary 16 gigabytes, while RAM in device 102 could support fewermemory cells such as less than an exemplary 8 gigabytes. Non-volatilememory for storage in a server 103 in FIG. 1a could comprise disks,“solid state drives” (SSDs) or “storage area networks” (SAN) for aserver. For a physical interface 102 a, in exemplary embodiments, aserver 103 in FIG. 1a could use a physical, wired LAN interface such asa high-speed Ethernet or fiber optic connection.

In exemplary embodiments, a device 102 can include the functionalcapabilities of (i) collecting sensor data, (ii) changing state of anactuator 102 z, (iii) communicating the data associated with a sensor oractuator with a wireless network, and/or receiving a challenge or noncefrom a server and sending a digital signature. The device driver 102 g,operating system 102 i, and/or device program 102 i could optionally becombined into an integrated system for providing the device 102functionality. Other possibilities exist as well for the configurationor combination of components illustrated in FIG. 1b without departingfrom the scope of the present disclosure.

FIG. 1c

FIG. 1c is a graphical illustration of hardware, firmware, and softwarecomponents for a device, including a tamper resistant element with aprimary platform, in accordance with exemplary embodiments. FIG. 1c isillustrated to include several components that can be common within a“system on a chip” (SOC) 109 and a manufactured TRE 113 with a PP 101.Device 102 may consist of multiple components in order to collect andtransmit transducer data from a sensor 102 f or an actuator 102 zassociated with device 102. In exemplary embodiments and as depicted inFIG. 1b above, device 102 can include and operate with the SOC 109,where SOC 109 can include a processor such as a central processing unit(CPU) or processor cores.

Device 102 can include a manufactured SOC 109. SOC 109 can includeseparate components of external pads 109 a, interface driver 109 b,processor cores 109 c, bus 109 d, memory core interface 109 m,nonvolatile memory 109 s, and TRE 113. Although TRE 113 is depicted asoperating in SOC 109, TRE 113 could also operate within a differentcomponent in device 102, such as physical interface 102 a (in FIG. 1babove), where physical interface 102 a could include a radio and abaseband processing unit. TRE 113 could also operate within a userinterface 101 j, and other possibilities exist as well without departingfrom the scope of the present disclosure, including TRE 113 operating asa “stand alone” module or chip soldered to a circuit board for device102.

The external pads 109 a of SOC 109 can provide an electrical interfacefor SOC 109 to connect with bus 102 d of device 102, such that theinternal components of device 102 can communicate with the internalcomponents of SOC 109, using a device driver 102 g, which could comprisePBL and PP agent 102 x. The external pads 109 a can include pins orelectrical contacts for electrical input into SOC 109 and such as apower voltage, electrical ground, a clock input, and data lines tocommunicate binary data. The external pads 109 a can support electricaloutput from SOC 109 as well. Although not separately depicted in FIG. 1c, a TRE 113 could also include electrical connectors similar to externalpads 109 a in order to transfer electrical signals from TRE 113 to SOC109.

Interface driver 109 b within SOC 109 can provide the firmware tosupport the selected physical bus type of both (i) bus 102 d andinternal bus 109 d and (ii) a communications protocol for transferringdata through the external pads 109 a. The interface driver 109 b canprovide functionality similar to device driver 102 g in FIG. 1b . Forexample, interface driver 109 b could support multiple different bustypes of a SPI bus, an I2C bus, a memory bus, and other possibilitiesexist as well for data transfer using the driver 109 b betweenprocessing cores 109 c and device 102 using bus 102 d, and otherpossibilities exist as well.

The processing cores 109 c can comprise a general purpose processingcores appropriate for typically low power consumption requirements for adevice 102 (compared to a server 103), and may also function as amicrocontroller. The processing cores 101 c can include at least oneprocessor core for device 102 such as an ARM® based processor or anIntel® based processor such as belonging to the Atom or MIPS family ofprocessors, and other possibilities exist as well including exemplaryCortex-M processors and cores. A single processor or processing corecould operate for processing cores 109 c as well. The processing cores109 c can also comprise specialized processing cores, such as includinghardware based cryptographic accelerators, field-programmable gatearrays (FPGAs), and other possibilities exist as well without departingfrom the scope of the present disclosure.

Internal bus 109 d can comprise at least one data bus to connect theinternal components of SOC 109, including TRE 113. Internal bus 109 dcan be a bus similar to bus 102 d for device 102 as depicted anddescribed in connection with FIG. 1b above. Although internal bus 109 dis depicted as extending into TRE 113, in exemplary embodiments twoseparate data buses could be utilized, and the two busses connected viaelectrical connections for TRE 113 similar to pads 109 a, where TRE 113manages the data flow between the two busses using an interfacecontroller 113 a.

SOC 109 can also include a memory core interface 109 m, where memorycore interface 109 m provides processor 109 c and/or TRE 113 access tophysical memory such as non-volatile memory 109 s and/or a RAM memorywithin SOC 109. RAM memory within SOC 109 and external to TRE 113 is notshown in FIG. 1c , but RAM memory similar to RAM 102 e for device 102could be included in SOC 109 and connected via internal bus 109 d.Processor 109 c and/or TRE 113 can read data from physical memory bywriting an address of a memory page and/or block to memory coreinterface 109 m, and memory core interface 109 m returns the data fromthe page in physical nonvolatile memory 109 s or a RAM memory for SOC109 or TRE 113.

Similarly, processor 109 c and/or TRE 113 can write data from physicalmemory by writing an address of a memory block and/or page to memorycore interface 109 m plus the data to be recorded in physical memory,and memory core interface 109 m can subsequently write the data tophysical memory at the block and page address specified. Otherpossibilities exist as well for the use of a memory core interface 109 mwithout departing from the scope of the present disclosure. In exemplaryembodiments, individual cells within a page can be addressed by a memorycore interface 109 m as well, and other possibilities for the structureand naming conventions of memory are possible without departing from thescope of the present disclosure.

Physical nonvolatile memory 109 s can comprise memory similar orequivalent to nonvolatile memory 102 s as depicted and described fordevice 102 above in FIG. 1b . Data recorded in memory 109 s can remainstored in SOC 109 when power is removed from SOC 109. Although memory109 s is depicted as located within SOC 109, (X) some memory cellsrecording data for SOC 109 could be located outside the physical housingof SOC 109 and/or TRE 113 and (Y) other memory cells recording data forSOC 109 could be located inside the physical housing of SOC 109. TRE 113and processor cores 109 c could access the physical nonvolatile memory109 s via a bus 109 d and a memory controller 109 m. In some exemplaryembodiments, a memory controller 109 m could operate with physicalnonvolatile memory both (i) inside SOC 109 and (ii) outside SOC 109 andwithin device 102.

Physical nonvolatile memory 109 s for SOC 109 can comprise at least adevice read/write memory 109 f and a TRE encrypted memory 109 g. Asnoted in the paragraph above some data or memory allocations depicted inFIG. 1c as recorded in memory 109 s in SOC 109 could be recorded orstored in nonvolatile memory 102 s for device 102. Device read/writememory 109 f can include a bound image 114 which has been downloadedfrom a secure session 108 as depicted in FIG. 1a above. Bound image 114can include a one-time public key for IDS server 103 such as PK-OT1.IDS1103 d-1, a ciphertext firmware key 106 a*, and ciphertext firmware 106*.Device read/write memory 109 f can also be referred to as device memory109 f. Device memory 109 f can also include general files for device 109i and free memory 109 x. General files for device 109 i can includefiles or data for the operation of device 102, such as data or librariesfor device programs 102 i, operating system 102 h, and device drivers102 g. Free memory 109 x can include unused or unallocated or freememory that is available for use by device 102 and/or TRE 113.

TRE encrypted memory 109 g can comprise memory within nonvolatile memory109 s that includes data and/or files for TRE 113 that are encrypted anddecrypted by TRE 113 using at least a symmetric ciphering key 127 and amemory controller 113 k, where memory controller 113 k is described inthe paragraph below. Symmetric ciphering key 127 can comprise a sequenceof pseudo-random digits unique for TRE 113 that are recorded in a readonly memory for TRE 113 as shown in FIG. 1c within EEPROM 113 c,although other possibilities exist as well for the location and formatof a symmetric ciphering key 127 for TRE 113 without departing from thescope of the present disclosure, such as recording key 127 in iNVM 113s. TRE encrypted memory 109 g can include ciphertext firmware 116*,where ciphertext firmware 116* can be different than ciphertext firmware106*. Ciphertext firmware 116* can be either (i) a different firmwarethan firmware 106 (e.g. include different plaintext processorinstructions for a different application than firmware 106) and/or (ii)be encrypted with symmetric key 127 instead of a firmware key 106 a. Inother words, ciphertext firmware 116* can comprise firmware that isencrypted by TRE 113 and managed by TRE 113 (such as stored by TRE 113for later loading or use) and ciphertext firmware 106* can comprisefirmware that is encrypted by an image maker 299 (in FIG. 2a below).

Data recorded in nonvolatile memory 109 g (or nonvolatile memory 102 s)may be (X) logically or physically separately from processor cores 109 cand device 102 for (Y) reading and writing exclusively by TRE 113through the use a memory controller 113 k. Memory controller 113 k canprovide physical or logical isolation of TRE 113 and TRE encryptedmemory 109 g such that device 102 or SOC 109 could not feasibly read orwrite valid ciphertext data to memory 109 g which could be subsequentlyread by TRE 113. For embodiments where TRE encrypted memory isphysically separated from other memory for device 102 in SOC 109,encryption could be optionally omitted and the memory 109 g could bereferred to as “TRE only accessible memory” 109 g.

As one example of physical separation of memory 109 g, the physicalmemory in SOC 109 comprising non-volatile memory 109 g could have aportion of the physical addresses reserved for reading and writing byTRE 113 only, such as an exemplary top 50 blocks of non-volatile memory109 g. Memory controller 113 k could intentionally disallow the transferof data from or to non-volatile memory 109 g to (i) processors 109 c or(ii) other components within SOC 109 or (iii) device 102 except for TRE113, where the block address is in the exemplary top 50 blocks. Memorycontroller 113 k could also operate on a lower level than a blockaddress for non-volatile memory 109 g as well, such as only allowing TRE113 or processor 113 b (discussed below in FIG. 1c ) to allow aspecified range of pages within non-volatile memory 109 g, where thespecified range of pages could belong to TRE encrypted memory 109 g.

In this manner, memory controller 113 k could operate as a firewall torestrict access for TRE encrypted memory 109 g to TRE 113. Otherpossibilities exist as well for the operation of a memory controller 113k in order to isolate and separate “TRE only accessible memory” or TREencrypted memory 109 g such that processor cores 109 c cannot feasiblyutilize, read from, or write to physical memory addresses for recordingand reading data utilized in “TRE only accessible memory” or “TREencrypted memory” 109 g. In addition, memory controller 113 k and TRE113 could utilize a memory bus 109 q such that only (i) data encryptedby TRE 113 would be written to TRE encrypted memory 109 g and (ii) datadecrypted by TRE 113 could be feasibly read in plaintext form by TRE 113using symmetric key 127. In other words, memory bus 109 q could be aphysical bus or a logical bus or circuit for TRE to access memory 109 g.Memory bus 109 q is not required in some exemplary embodiments, andmemory controller 113 k could be connected to data bus 109 d, but limitaccess to physical memory cells comprising memory 109 g to processor 113b. Other possibilities for limiting access to memory 109 g to TRE 113are possible as well without departing from the scope of the presentdisclosure.

In another embodiment, memory controller 113 k could performhardware-based encryption/decryption using a symmetric key 127 toencrypt and decrypt data transferred between TRE 113 and TRE encryptedmemory 109 g. In an exemplary embodiment, TRE encrypted memory 109 g canbe formatted with a file system with a separate partition from thememory that device 102 and SOC 109 accesses within memory 109 f. A filesystem on TRE encrypted memory 109 g could be encrypted using asymmetric ciphering algorithm from cryptographic algorithms 141 asymmetric key 127 recorded by TRE 113, such that even if TRE encryptedmemory 109 g could be accessed by device 102 or SOC 109, no useful datacould be extracted or tampered with.

Although memory controller 113 k is depicted in FIG. 1c as a separateelement from memory core interface 109 m, memory controller 113 k couldalso be optionally integrated with memory core interface 109 m, andother possibilities exist as well for the operation and location of amemory controller 113 k for ciphering data or restricting access to datarecorded in SOC 109 for TRE 113, without departing from the scope of thepresent disclosure.

SOC 109 or device 102 can include tamper resistant element (TRE 113).TRE 113 can also be referred to as a “secure element”, “secure enclave”,“secure environment”, or also a trusted execution environment (TEE) orsmart secure platform (SSP). As depicted in FIG. 1c , TRE 113 cancomprise the physical hardware with components consisting of at least aninterface controller 113 a, a CPU 113 b, memory controller 113 k, RAM113 e, internal nonvolatile memory (iNVM) 113 s, an internal bus 109 dwhich could be segmented and a distinct subset of a bus 109 d that isexternal to TRE 113 and internal to SOC 109, a hardware-based randomnumber generator 128, a transducer 113 z, and an Electrically ErasableProgrammable Read-Only Memory (EEPROM) 113 c. The connection of thesubset of bus 109 d inside TRE 113 and the external portion of bus 109 dwithin SOC 109 could be managed by interface controller 113 a.

TRE 113 can include a primary platform identity PP-ID 101 i. PP-ID 101 icould comprise a preferably unique alpha-numeric or hexadecimalidentifier for PP 101, such as a universal unique identifier (UUID), anInternational Mobile Equipment Identity (IMEI), an owner interfaceidentifier in an IPv6 network, a serial number, or other sequence ofdigits to uniquely identify each of the many different possible unitsfor PP 101 in a system 100 and other systems herein. PP-ID 101 i canpreferably be recorded in a non-volatile memory or written directly tohardware in TRE 113 by a TRE manufacturer upon TRE 113 manufacturing.

CPU 113 b can comprise a processor embedded into the TRE 113 andconsequently typically with less resources than processing cores 109 c,such as (i) less cache memory, (ii) operating typically at a slowerspeed, (iii) fewer internal registers, (iv) lower power consumption dueto reduced thermal dissipation for a TRE 113 compared to device 102,etc. CPU 113 b with interface controller 113 a can also manage andsequence the flow of data between TRE 113 and the portion of the bus 109d extending to TRE 113. CPU 113 b can also process other functions suchas operating a set of cryptographic algorithms 141 recorded in bootfirmware 121 or other cryptographic operations within a downloadedand/or operating firmware 106. CPU 113 b could conduct the processing,computational, and logical steps for TRE 113 and PP 101 as depicted inFIG. 2a and FIG. 3 below, as well as other Figures herein.

The processor 113 b in TRE 113 can function similar to processor cores109 c for SOC 109 as described above. However, processor 113 b canoperate with a form factor, speed, and computational capacity suitablefor TRE 113. Processor 113 b in TRE 113 could be a processor belongingto the exemplary Imps®, ARM®, or Intel® family of processors, and otherpossibilities exist as well. Processor 113 b can include components suchas registers, accumulators, and logic elements to add, subtract,multiply, and divide numerical values, and processor 113 b can beconnected to data bus 109 d. The timing of processor 113 b and data bus109 d can be driven by a clock, which could be either (i) operatinginternal to TRE 113 and connected to bus 109 d or (ii) operatingexternal to TRE 113 and input to TRE 113 via bus 109 d. Processor 113 bcan provide the hardware for TRE 113 to perform calculations forcryptographic algorithms 141 in addition to the general operation of TRE113 and managing communication between TRE 113 and SOC 109 throughelectrical connections similar to electrical pads 109 a. Processor 113 bcould also be connected to internal bus 109 q. When TRE 113 has receivedelectrical power and loaded boot firmware from EEPROM 113 c, then TRE113 using processor 113 b can operate as a primary platform 101.

EEPROM 113 c could also comprise a read only memory, where the data inEEPROM 113 c is written once upon manufacturing of SOC 109. EEPROM 113 ccould also function as a read only memory for TRE 113 similar to ROM 102c for device 102 above. In other words, EEPROM 113 c does not need to beerasable and reprogrammable, although some data in EEPROM 113 c could bere-written in exemplary embodiments. EEPROM 113 c could comprise anonvolatile flash memory based on NAND or NOR memory cell technology,and other possibilities exist as well without departing from the scopeof the present disclosure. The contents of EEPROM 113 c will bediscussed in additional detail below for this FIG. 1c . Althoughdepicted as using EEPROM 113 c, the data and elements depicted withinEEPROM 113 c in FIG. 1c could be alternatively stored in an internalnonvolatile memory (iNVM) 113 s, where the memory within 113 s is taggedor set as being “read only” during most of the life of operation of TRE113. In other words, a physical EEPROM chip or memory cells are notrequired for some embodiments in order to implement the functionality ofEEPROM 113 c depicted in FIG. 1 c.

Random access memory 113 e in TRE 113 can function similar to RAM 102 efor device 102, with a form factor, speed, and storage capacity suitablefor TRE 113. RAM 113 e can be connected to an internal data bus 109 d inTRE 113 (where (X) the internal data bus 109 d in TRE 113 can beseparate from (Y) the internal bus 109 d outside TRE 113 and in SOC109). RAM 113 e and can store data for processor 113 b in a volatilestate, such that data recorded in RAM 113 e can be essentially flushedor reset when electrical power to SOC 109 and TRE 113 is removed. Randomaccess memory 113 e can store data such as tables of memory addressesand sectors for memory 109 g and memory 113 s, since these tables areordinarily larger than the registers provided by CPU 113 b.

For some exemplary embodiments, although depicted as separate elementsfor both (i) processor cores 109 c, and RAM 113 e, and (ii) CPU 113 eand RAM 113 e, the two elements (processor and RAM) could comprise thesame physical hardware but represent time division or time separation ofthe physical hardware, similar to how the same physical hardware canhost multiple logical processes running concurrently In other words,processor cores 109 c could switch operations between a “normal” modefunctioning as a CPU for device 102 and then a “secure” mode as TRE 113for device 102. Or, CPU 113 b could represent a virtualized process orcomputer within device 102, where the OS 102 h implements virtualizationand operates as a host for TRE 113. Switching could take place rapidlyenough that processor 109 c and TRE CPU 113 b would appear to othercomponents (both inside and outside device 102) as separate processors,while there could be a single physical processor inside device 102 suchas within SOC 109.

As depicted in FIG. 1c , TRE 113 can include a transducer 113 z, wheretransducer 113 z could comprise a sensor and/or a radio. Transducer 113z can also be referred to as a radio 113 z. Radio 113 z could supportNFC communication. Although illustrated as internal to TRE 113, radio113 z could be external to TRE 113 in some embodiments. A radio 113 zthat is external to TRE 113 but internal to SOC 109 could be connectedvia a secure bus such as bus 109 d. In some embodiments, bus 109 d canextend outside SOC 109 and/or TRE 113 in order to connect externalcomponents for SOC 109 with internal components for SOC 109 and TRE 113.

Radio 113 z can comprise a radio for short-distance wirelesscommunication, and be connected with an antenna. Radio 113 z, whenoperating to support NFC communications, could (i) transmit and receiveat the globally available frequency for unlicensed use of 13.56 Mhz, and(ii) be compatible with the International Standards Organization (ISO)14443 standards and subsequent and related versions. Radio 113 z canoperate as any of an NFC reader, NFC writer, and NFC peer-to-peercommunication, and preferably supports communication at short range suchas within several inches of SOC 109 and TRE 113. Radio 113 z, whenoperating as an NFC radio, can support radio frequency communicationswith another NFC radio, when device 102 with SOC 109 is within closephysical proximity of the other NFC radio, such as less than a few feetin an exemplary embodiment.

A benefit of the use of short-range communication for radio 113 z isphysical security, such that any external device desiring to communicatewith TRE 113 through radio 113 z must be in close physical proximity. Inexemplary embodiments radio 113 z could support other short-rangewireless standards besides NFC. Radio 113 z could implement radiofrequency protocols that utilize low power and close proximity for theother node for which TRE 113 will communicate with. In exemplaryembodiments, radio 113 z could be a Bluetooth or WiFi radio, but operateat intentionally reduced in order to require closer physical proximityfor an external device such as a mobile phone to communicate with TRE113 using radio 113 z. For embodiments where radio 113 z operates as aBluetooth or WiFi radio, radio 113 z could transmit at a power in anexemplary range of 0.001-0.1 watts. Other possibilities for the radiotechnology and power levels of radio 113 z exist without departing fromthe scope of the present disclosure.

TRE 113 can also include an embedded sensor for a transducer 113 z. Asensor as a transducer 113 z could comprise a sensor similar to sensor102 f for device 102, with a difference that a sensor for transducer 113z can be sufficiently small to be enclosed by the housing for TRE 113along with the other components illustrated in FIG. 1c . In exemplaryembodiments the analog output of a sensor for transducer 113 z can beconverted to digital form by CPU 113 b and utilized as input, along withother data, into a random number seed 128 b within random numbergenerator 128 in TRE 113. A sensor for a transducer 113 z could collectanalog data, such as temperature, pressure, thermal noise in siliconwithin TRE 113, or other environmental variables, with a sufficientnumber of significant digits, such that the trailing digits couldcomprise an effective noise value. Or, the combination of many differentmeasurements by a sensor as transducer 113 z could comprise anessentially random value or a number with enough randomness for use withcryptographic operations.

As illustrated in FIG. 1c , TRE 113 and SOC 109 may also contain arandom number generator 128. Random number generator 128 can comprise aphysical component that generates random or pseudo random numbers forcryptographic operations of TRE 113 and PP 101. A random numbergenerator 128 can also comprise a hardware random number generator. Thecreation of random numbers with a high degree of entropy is important inthe use of subsequent steps such as generating a value for SK-OT1.PP 101c-1 (where TRE 113 derives the one-time or ephemeral keys). Or, randomnumbers from random number generator 128 could be used with the creationof nonce values or challenge values for use with digital signatures.Random number generator 128 can be used to create random number 208 b asdepicted and described in connection with FIG. 2a below.

Random numbers from random number generator 128 could be used to createa symmetric ciphering key 127, and other possibilities exist as well. Aseed 128 b for random number generator 128 could comprise a plurality ofdata from within TRE 113 appended together in order to accumulateinformation entropy. To acquire the seed 128, TRE 113 could collect aplurality of transducer 113 z measurements or states, radio 113 zmeasurements, clock times or values for CPU 113 b, RAM 113 e or memory109 g states, etc. In exemplary embodiments, random number generator 128can include a secure hash algorithm operating on the random number seed.In exemplary embodiments, random number generator 128 operates withinTRE 113 as depicted in FIG. 1c , and in this manner the random numbersused for cryptographic operations such as PM key generation for thesecret or private key for PP one-time keys 101 e can remain reasonablysecure and not normally communicated outside TRE 113. Random numbergenerator 128 could also be used to derive PM keys for TRE in support ofthe operation of a firmware 106, where firmware 106 could conductcryptographic operations for an application on device 102.

EEPROM 113 c in TRE 113 can include a PP certificate 120, PP bootfirmware 121, CU boot configuration 123, certificate authority publickey 131, certificate authority public key parameters 104 a′, a primaryplatform private key 115 a, and a symmetric key 127. PP private key 115a and symmetric key 127 can be recorded in a protected memory 125 innonvolatile memory 113 c, similar to TRE only accessible memory 109 g,such that (i) only TRE 113 can read PP private key 115 a usinginstructions in PP boot firmware 121 or firmware 106, and (ii) PPprivate key 115 a may not be read by device 102 or transferred out ofTRE 113 in exemplary embodiments. In exemplary embodiments, PP bootfirmware 121 or firmware 106 can omit instructions that would allow PPprivate key 115 a to be transferred to electrical pads 109 a.

Note that PP private key 115 a could be used for digital signatureoperations by TRE 113, and key 115 a can be different than primaryplatform private key 101 a used for downloading firmware 106. For otherembodiments, key 115 a could be the same as key 101 a (such asembodiments where device 102 represents a more resource constrainedsystem where separate keys for 101 a and 115 a may have higher coststhan benefits). EEPROM 113 c can also include PM keys of at leastSK-static.PP 101 a and IDS static public keys 103 p. By recording thekeys in EEPROM 113 c during manufacturing, the values can be fixed andTRE 113 can be reasonably assured about the security and integrity ofthese keys during operation.

Data within EEPROM 113 c can comprise PP certificate 120, PP bootfirmware 121, PP boot configuration 123, certificate authority publickey 131, and certificate authority public key parameters 104′. Data canbe written to EEPROM 113 c by a TRE configuration unit duringmanufacturing of TRE 113. The data in EEPROM 113 c for TRE 113 can bewritten into EEPROM 113 c in TRE 113 and SOC 109 before SOC 109 isdistributed to a manufacturer of device 102. PP certificate 120 can bewritten to EEPROM 113 c by a TRE configuration unit (i) after thegeneration of PP private key 115 a, and (ii) after the signature of thecorresponding PP public key 115 b by a certificate authority.

PP certificate 120 can include the PP identity PP-ID 109 i, PP publickey 115 b (corresponding to PP private key 115 a), certificateparameters 104′, and a certificate authority digital signature 116. PPcertificate 120 can be formatted according to the X.509 v3specifications, among other possible formats, and stored as a plain textfile, *.pem file, or *.crt file or similar file formats. PP certificate120 can be used by TRE 113 and SOC 109 in order to (i) verify identityof TRE 113 to device 102 or a server such as server 103 (includingverifying identity of TRE 113 to a network), or (ii) generate a digitalsignature for an internally generated or derived PM key pair, such asPK-OT1.PP 101 d-1. In exemplary embodiments, parameters 104′ in CUcertificate 120 can include an expiration time of PP certificate 120longer than the expected operational lifetime of TRE 113, and in thismanner PP certificate 120 can remain valid whenever SOC 109 is utilized.An exemplary expiration time of PP certificate 120 could be 25 years,although other possibilities exist as well.

PP boot firmware 121 in EEPROM 113 c can provide machine executable codefor processor 113 b to initiate operations when electrical power isprovided to TRE 113 and SOC 109 via the electrical pads 109 a. Althoughnot illustrated in FIG. 1c , processor 113 b may also include a ROMmemory with CPU 113 b instructions for CPU 113 b to fetch PP bootfirmware 121 upon startup when power is provided to CPU 113 b. Inexemplary embodiments, PP boot firmware 121 could comprise a “PrimaryBoot Loader” as contemplated by the GSMA PP requirements document, andother possibilities exist as well. PP boot firmware 121 can include aset of cryptographic algorithms 141, described in the paragraph below,and memory control libraries 122. PP boot firmware 121 in EEPROM 113 ccould also include instructions for TRE 113 to load a firmware 116*recorded in non volatile memory 109 g, where a plaintext firmware 116can comprise a base image for the operation of primary platform 101.

Cryptographic algorithms 141 in memory 113 c can comprise digitalsignature algorithms such as ECDSA or DSA, symmetric cipheringalgorithms such as AES and TripleDES, key exchange algorithms, key pairgeneration algorithms, random number generators, secure hash algorithmssuch as SHA-2 or SHA-3, and asymmetric ciphering algorithms such as Elgamal or RSA. Libraries in cryptographic algorithms 109 q could be fromstandard open source libraries such as OpenSSL, crypto++, Bouncy Castle,or Mozilla libraries from Network Security Services, and otherpossibilities exist as well. Example calculations and functions from theuse of cryptographic algorithms 141 are depicted and described inconnection with FIGS. 2b , FIG. 2c , and FIG. 3 below.

In exemplary embodiments, ciphertext firmware 116* could be decryptedwith a symmetric key 127 recorded in EEPROM 113 c. Authorized providersof firmware 116*, such as image maker 299 in FIG. 2a below or perhapsSOC manufacturer, could have access to a symmetric key 127 for TRE 113with PP-ID 109 i, and consequently only the authorized providers couldproperly encrypt firmware 116* using the symmetric key 127. Note thatTRE 113 could use multiple different values for symmetric key 127, suchthat a first key 127 is used with a first firmware 116* (which could beprovided by a TRE 113 manufacturer) and a second key 127 could bederived by TRE 113 for encrypting storing subsequently downloadedfirmware 106 as a second firmware 116* in memory 109 g. For someexemplary embodiments, firmware 116* could be transmitted to a device102 over IP network 107 in the encrypted format. In exemplaryembodiments, a symmetric key 127 for TRE 113 will be unique for eachdifferent SOC 109, and each symmetric key 127 can be uniquely associatedwith a PP-ID 109 i. Thus, symmetric key 127 within TRE 113 can comprisea shared secret key for some embodiments. In some exemplary embodiments,firmware 116 is not required for TRE 113 to operate, and TRE 113 couldoperate using PP boot firmware 121.

Memory control libraries 122 could include software or firmware tomanage and schedule the operation of TRE 113, such as machine code for(i) instructing processor 113 b to write data to bus 109 q for memorycontroller 113 k when data is recorded in memory 109 g, (ii) read datafrom bus 109 d when data from SOC 109 is passed to TRE 113, (iii)reading PP private key from protected memory 125 or protected memory 113i when cryptographic algorithms 141 for TRE 113 need the private keysfor cryptographic operations such as a key exchange or digitalsignatures. Memory control libraries 122 can include the softwarelibraries and firmware for processor 113 b to manage all input andoutput of TRE 113, including embodiments where TRE operates as aseparate component connected to bus 102 d and separate from SOC 109.Other possibilities exist as well for memory control libraries 122 tosupport the operation of TRE 113 and SOC 109 via program instructionsprovided to processor 113 b without departing from the scope of thepresent disclosure. Note that memory control libraries 122 could alsoallow PP 101 to operate multiple different firmware 106 concurrently,such as for encapsulating and isolating data for each firmware 106, suchthat different firmware 106 could not read or write to data within TRE113 that does not belong to the firmware 106.

Memory control libraries 122 can also include PP read instructions 151and PP write instructions 152. PP read instructions 151 can providemachine executable code for processor 113 b to read data from device 102and/or SOC 109 using a data bus 109 d or bus 109 q. PP read instructions151 can provide the read libraries for firmware 106 to call in order forfirmware 106 (or firmware 116) to read data from physical memory withinTRE 113. The data read from physical memory by PP read instruction 151for a firmware 106 could be used with cryptographic algorithms 141 byTRE 113. In this manner, PP read instructions 151 could provide both (i)the logical software or firmware interface for TRE 113 to receive datafrom device 102 and (ii) isolate data for different firmware 106operating in PP 101.

PP read instructions 151 could specify memory addresses or filelocations in a file system for non-volatile memory 109 s or memory 113 sor memory 113 e. For example, PP read instructions 151 could be used byPP 101 for data in memory 109 s where device 102 can write data in orderto be read by TRE 113. In an exemplary embodiment, (i) device 102 couldwrite a file with an exemplary name “firmware_update_version_1.5” (whichcould comprise a bound image 114 with ciphertext firmware 106*) to aspecified location in device memory 109 f. Then, after commands from PBLand PP agent 102 x, (ii) PP read instructions 152 could instructprocessor 113 b to read the bound image 114 data and subsequentlyprocess the bound image 114 data with firmware decryption step 112.

EEPROM 113 c in TRE 113 for SOC 109 can also include a PP bootconfiguration 123, a certificate authority public key 131, certificateauthority public key parameters 104 a′, a PP private key 115 a and asymmetric key 127. PP boot configuration 123 can provide values for theconfiguration or operation of TRE 113 when operating with the PP bootfirmware 121, such as specifying (i) the frequency to operate a bus 109d for data input SOC 109 or device 102, (ii) the frequency to operate aprocessor 113 b as well as processor configuration settings, (iii) aboot firmware version number, (iv) the memory capacity of memory 109 gfor TRE 113 or iNVM 113 i, and (v) parameters specifying values forhardware within TRE 113 or radio/transducer 113 z.

Certificate authority (CA) public key 131 can be utilized by TRE 113 toverify digital signatures received where the digital signature wasgenerated and signed with a CA private key, such as a certificate for aserver. CA public key parameters 104 a′ can specify the parameters forusing the CA public key 131, where parameters 104 a′ can be a subset ofthe parameters 104 supported by cryptographic algorithms 141. Exemplaryparameters 104 are depicted and described in connection with FIG. 4below, such as specifying a key length, digital signature algorithm 141d and secure hash algorithm 141 c to utilize, etc. Note that parameters104 a′ for CA public key 131 and parameters 104 a for a PP static publickey of PK-static.PP 101 b and/or PP private key 115 a can be different.

Although a single CA public key 131, PP private key 115 a, symmetric key127, and PP certificate 120 is depicted in FIG. 1c , an EEPROM 113 c orSOC 109 could record a plurality of each of these and associatedelements. For example TRE 113 could record two different private keys115 a in EEPROM 113 c, where a first private key 115 a is used withasymmetric ciphering algorithms (such as El Gamal based encryption) anda second private key 115 b is used with digital signature algorithms.Each of the first and second private keys could have a correspondingpublic key 115 b, and consequently two different PP certificates 120(each with a different public key 115 b) could be recorded in an EEPROM113 c. CA public key 131 could also be used with asymmetric cipheringalgorithms in 141, such that TRE 113 could encrypt data using the CApublic key 131 and the certificate authority could subsequently decryptthe encrypted data using the CA private key corresponding to the CApublic key 131.

In exemplary embodiments, initial PM keys for SOC 109 may be recorded inEEPROM for TRE 113 as shown in FIG. 1c , and subsequent or updatedversions of the keys can be recorded in memory 109 g or memory 113 s.Certificate Authority (CA) Public Keys 131 can also record a set of rootcertificates for TRE 113 and SOC 109 to use with verification ofcertificate authority digital signatures for certificates such as aserver certificate 103 t. Root certificates recorded in CA public keys131 can comprise the list or a subset of the list of included rootcertificates from the Mozilla Foundation with Mozilla projects, wherethe aggregate list of community approved root certificates andassociated parameters is in the widely distributed file certdata.txtfrom the Mozilla web site.

TRE 113 can include internal nonvolatile flash memory iNVM 113 s, whichcan also be referred to as “nonvolatile memory 113 s” or “memory 102 s”.Nonvolatile memory 102 s can comprise a physical memory of NAND or NORflash memory, or other nonvolatile memory types including a persistentmemory or nonvolatile random access memory (NVRAM), such that datastored or written by TRE 113 to nonvolatile memory 113 s continues to bestored or recorded when electrical power is removed from device 102 orSOC 109 or TRE 113. The data within non-volatile memory 113 s cansubsequently be read and other data re-written when power is restored toTRE 113. Some components of a plaintext firmware 106 for TRE 113 can bestored in memory 113 s, such as cryptographic keys including privatekeys such a long-term secret symmetric key K for 5G networks or 4Gnetworks, an identifier for device 102 with a 3GPP or ETSI wirelessnetwork such as an international subscriber identity (IMSI) orsubscriber permanent identity (SUFI).

In exemplary embodiments, the wireless network could also record the keyK in an authentication center or authentication credential repositoryand processing function (ARPF) in order to conduct an authenticated keyagreement (AKA) key exchange between the wireless network and device102, where device 102 records and operates with the key K and identityinformation in TRE 113. Other keys from a firmware 106 could be recordedin iNVM memory 113 s as well including private keys such as a privatekey of the eUICC for creating signatures comprising a keySK.EUICC.ECDSA. Other possibilities exist as well for private keysdescribed in the present disclosure to be stored or recorded in aninternal nonvolatile memory iNVM 113 s for a TRE 113 without departingfrom the scope of the present disclosure.

FIG. 2a

FIG. 2a is a simplified message flow diagram illustrating an exemplarysystem with exemplary data sent and received by a device with a primaryplatform, a server, and an image maker, in order to securely transfer afirmware for the primary platform to the device, in accordance withexemplary embodiments. System 200 can include a device 102, server 103,and an image maker 299. Device 102 and components in device 102 weredepicted and described in connection with FIG. 1a , FIG. 1b , and FIG.1c above. Server 103 was depicted and described in connection with FIG.1a , and the components in server 103 were also described in connectionwith FIG. 1b above. Image maker 299 can comprise a collection of serverssimilar to server 103, where a primary function for operation of imagemaker 299 is to create firmware 106 for device 102 operating a primaryplatform 101 in a tamper resistant element (TRE) 113. Although a singledevice 102, server 103, and image maker 299 are depicted in FIG. 2a , asystem 200 could include a plurality of each of the devices and serversshown. Device 102, server 103, and image maker 299 can communicate usingan IP network 107, which could also comprise an Internet as depicted anddescribed in connection with FIG. 1a above.

Device 102 can include a TRE 113, a primary boot loader (PBL) and PPagent 102 x, and a secure session library 102 y. Components within TRE113, such as a primary platform 101 were depicted and described inconnection with FIG. 1b and FIG. 1c above. PBL and PP agent 102 x cancomprise a secure driver or a device driver for TRE 113, such thatdevice 102 can send and receive data with TRE 113 using a data busoperating within device 102 such as a bus 102 d or a bus 109 d. Securesession library 102 y can comprise a firmware or software library fordevice 102 to securely communicate with external nodes from device 102and establish secure sessions through a physical interface such as aradio for device 102. Secure session library 102 y was depicted anddescribed as a device program 102 i operating in device 102 in FIG. 1babove, and other possibilities exist as well. As depicted in FIG. 2a ,communication between secure session library 102 y and PBL and PP agent102 x can be through a bus 102 d and/or a bus 109 d and an operatingsystem 102 h for device 102. In other words, data transfer betweensecure session library 102 y and PBL and PP agent 102 x can be managedby an operating system 102 h for a device 102 using a data bus and/orinternal memory such as RAM 102 e. Other possibilities exist as well fora device to communicate data with a server and also internallycommunicate the data with a TRE 113 without departing from the scope ofthe present disclosure.

Server 103 can record and operate a server database 103 d, where serverdatabase 103 d was also depicted and described in FIG. 1a as a “primaryplatform database” 103 d. Individual steps and components used in system200 in FIG. 2a are also additionally depicted and described insubsequent FIGS. 2b, 2c, and 2d , etc.

Image maker 299 can comprise the source of a firmware 106 for a primaryplatform 101 operating in device 102. Although a single image maker 299is depicted in FIG. 2a , a system 200 could include a plurality ofdifferent image makers 299, and a server 103 could select an image maker299 based on data received from device 102. Many possibilities exist forthe source and operation of a firmware 106 from an image maker 299without departing from the scope of the present disclosure. A firstimage maker 299 could create a first firmware 106 which operates as anembedded SIM for M2M devices, such as specified in GSMA standardsSGP.02. A second image maker 299 could create a second firmware 106which operates as an embedded SIM for consumer devices, such asspecified in GSMA standard SGP.22. The operation of primary platform 101as an embedded SIM may also be referred to as an embedded “Smart SecurePlatform” (eSSP). Or, the first image maker 299 could create both thefirst and second firmwares 106. A third image maker 299 could create afirmware 106 for the operation of primary platform 101 as an integrated“Smart Secure Platform” (iSSP). Further, image maker 299 could createfirmware 106 for other secure functions of a primary platform 101operating in a secure environment such as TRE 113 for device 102,including digital identification, electronic payments, authenticationtokens, etc. without departing from the scope of the present disclosure.As discussed above, a plaintext firmware 106 can provide machineexecutable instructions and cryptographic data such as algorithms andkeys for a TRE 113 to conduct secure cryptographic operations for device102 using firmware 106.

At step 201, TRE 113 can be manufactured, where the exemplary componentsfor a TRE 113 from FIG. 1c can be assembled and connected within ahousing for TRE 113. Or, if TRE 113 comprises a separate processing corefor a CPU or SOC 109, a step 201 can comprise manufacturing the TRE 113in a secure environment. A step 201 can include TRE 113 securelyrecording or storing data depicted in FIG. 1a including at least (i) aserver static public key PK.IDS1 103 b (ii) a primary platform staticprivate key SK-static.PP 101 a, (iii) a set of cryptographic parameters104, and (iv) a primary platform identity PP-ID 101 i. For someembodiments, an TRE 113 could omit recording the data for IDS 103 in astep 201 and receive the data in an authenticated and secure manner at alater time, such as later receiving a certificate for PK.IDS1 103 b andverifying the certificate (and/or chain of certificates) using CA publickey 131. In general, TRE 113 receives a server public key 103 b for IDS103 before conducting a key exchange 110 b step below.

A step 201 can include writing configuration and boot data to TRE 113 asdepicted in FIG. 1c , including PP boot firmware 121, cryptographicalgorithms 141, PP boot configuration 123, CA public key 131, PP privatekey 115 a, PP certificate 120, etc. In addition, a collection of PPone-time keys 101 e could be stored in TRE 113 at a step 201, if TRE 113does not derive the PP one-time keys 101 e at a later time, such as astep 208 below or for a message 209 below (where message 209 can includea PK.OT1.PP 101 d-1). In exemplary embodiments, a primary boot loader(PBL) for PP 101 can comprise the collection of data and boot firmwarewritten to TRE 113 in a step 201 during manufacturing. A primary bootloader can comprise the PP boot firmware 121. The configuration portionof a step 201 for TRE 113 could also be conducted after manufacturing ofa TRE 113, but before distribution of a TRE 113 to end users or device102 manufacturers.

At step 202, device 102 can be manufactured, where the exemplarycomponents for a device 102 from FIG. 1b can be assembled and connectedwithin a housing for device 102. In exemplary embodiments, a TRE 113 canbe connected to other components in device 102 using a bus 102 d. A step202 can also comprise device 102 being configured, such as storing innonvolatile memory 102 s for device 101 an operating system 102 h,device drivers 102 g including PBL and PP agent 102 x, a device identity102 k, a secure session library 102 y, etc. A step 202 can includedevice 102 being distributed to end users such that device 102 can beginoperating “in the field” or outside a manufacturing facility.

At step 203 a, IDS server 103 can record a set of cryptographicparameters 104 and a server static private key SK.IDS1 103 a, which cancorrespond to the server static public key PK.IDS1 103 b recorded by TRE113 in a step 201. As contemplated herein, when a node or computingdevice such as a server 103 or TRE 113 is described as storing orrecording a private key, the node or computing device may also recordthe corresponding public key concurrently. Or, the computing devicecould optionally record only the private key and then subsequentlygenerate the public key using cryptographic parameters 104 (which couldinclude a base point G for multiplying the private key in order toobtain the public key). Thus, a computing device could utilize or storea public key whenever a private key is recorded.

Continuing at step 203 a, for some embodiments, an IDS server 103 couldalso record a primary platform static public key PK-static.PP 101 b anda primary platform identity PP-ID 101 i in a database 103 d in a step203 a. An IDS server 103 could receive the PK-static.PP 101 b and PP-ID101 i from a manufacturer of TRE 113 after a step 201 above. Or, forother embodiments, an IDS server 103 could omit recording the data forPP 101 in a step 203 a and receive the data in an authenticated andsecure manner at a later time, such as later receiving a certificate forPK-static.PP 101 b and verifying the certificate. For either embodiment,IDS server 103 receives a public key 101 b for primary platform 101before conducting a key exchange 110 a step below.

At 203 b, image maker 299 generates or processes firmware 106 forprimary platform 101 operating in TRE 113. Image maker 299 could createa common firmware 106 for a collection of devices 102 with TRE 113, suchas a firmware 106 comprising a Java applet or application for operatingan embedded universal integrated circuit card (eUICC) or simply anintegrated universal integrated circuit card (iUICC). Firmware 106 couldalso be machine executable code, such as byte code, for other platformsas well and may also support other applications such as firmware forrunning or operating a “Smart Secure Platform” within TRE 113. A step203 b can comprise compiling or assembling source code for firmware 106into machine executable code. A first firmware 106 in a step 203 b couldbe for a first processor type of CPU 113 b and PP boot firmware 121 fora first class of device 102, and a second firmware 106 in a step 203 bcould be for a second processor type of CPU 113 b and PP boot firmware121 for second class of device 102, and other possibilities exist aswell. In exemplary embodiments, image maker 299 can comprise acollection of servers, such that a first server processes the firmware106 offline and encrypts the data of firmware 106 before storing theciphertext firmware 106* in a second server for image maker 299, wherethe second server is connected to IP network 107 with IDS server 103.

After a step 203 b, image maker 299 can conduct a step 203 c to derive asymmetric ciphering key which can comprise a firmware key 106 a.Firmware key 106 a could be derived using a random number generatorequivalent to a random number generator 128 from FIG. 1c and a securehash algorithm. For some embodiments where firmware key 106 a couldcomprise an SSD container as contemplated by the GSMA PP Requirementsdocument, a firmware key 106 a could comprise at least one public keyassociated with image maker 299 instead of or in addition to a symmetricciphering key. In other words, a firmware key 106 a as contemplated bythe present disclosure could comprise keys more than a symmetricciphering key.

At step 203 c, image maker can conduct an encryption of firmware 106using the firmware key 106 a, where encryption of a plaintext firmware106 into a ciphertext firmware 106* is depicted and described inconnection with FIG. 2b below. The firmware 106 for a step 203 c cancomprise the firmware 106 generated in a step 203 b above. Forembodiments where the firmware key 106 a includes at least one publickey associated with or for the image maker 299, the at least one publickey for the image maker in the firmware key 106 a could be used in asubsequent key exchange in order to derive a symmetric ciphering key,where the derived symmetric ciphering key using the public key for imagemaker 299 could be used to encrypt plaintext firmware 106 intociphertext firmware 106*. In other embodiments, the firmware key 106 acan comprise a symmetric ciphering key.

The operation and function of an encryption step 203 c with a firmwarekey 106 a is depicted and described in connection with FIG. 2c below.The output or result of an encryption step 203 c can comprise aciphertext firmware 106*. Image maker 299 can transfer ciphertextfirmware 106* to a server that communicates with IDS server 103 via IPnetwork 107, such that the ciphertext firmware 106* is available fortransfer to server 103. Note that ciphertext firmware 106* (and otherciphertext data as contemplated herein) may also include non-ciphertextmetadata such as a file name, file size, operating system for the file,file processing date, a key identifier or identity for the correspondingdecryption key comprising firmware key 106 a, etc.

For system 200, server 103 and image maker 299 may establish a securesession 203 d, which could comprise establishing a secure communicationslink between the two servers using protocols such as TLS, IPSec, avirtual private network (VPN), a secure shell (SSH), or similarnetworking, transport, or application layer technologies in order toestablish secure communications between image maker 299 and server 103.Secure session 203 d can utilize certificates for the two servers inorder to provide mutual authentication and mutual key derivation for asymmetric encryption key in secure session 203 d. As depicted in FIG. 2a, the certificates could comprise a first certificate 103 t for server103 and a second certificate 299 t for image maker 299. Secure session203 d can also be conducted over private IP network 107. Otherpossibilities exist as well for establishing a secure session 203 dbetween server 103 and image maker 299 without departing from the scopeof the present disclosure. Although not depicted in FIG. 2a , firewallsbetween server 103 and image maker 299 could also be utilized in orderto establish or conduct secure session 203 d. After step 203 a, IDSserver 103 can begin listening for incoming messages from a device 102using a physical network interface that provides connectivity to the IPnetwork 107 and server 103 can use a specific port number such as TCPport 443 to listen for incoming secure session 108 from a device 102.

At step 204, device 102 can power up or boot, load PBL and PP agent 102x, and provide power to TRE 113. Device 102 can then be configured toread and write data with TRE 113 using PBL and PP agent 102 x. At step204, TRE 113 can boot and use boot firmware 121 and boot configuration123 to begin operation at least as a primary boot loader. In addition,if an existing primary platform firmware 116* is recorded in memory suchas memory 109 s or iNVM 113 s, then primary platform 101 could, afterboot, decrypt with key 127, load, and operate with firmware 116. Inexemplary embodiments, firmware 116 could comprise a host for operatingvirtual machines, and firmware 116 could also be written to iNVM 113 sduring a manufacturing step 201 for TRE 113.

After a step 204, where device 102 and TRE 113 boot and begin operatingin a step 204, PBL and PP agent 102 x can submit a query 205 a to TRE113. Query 205 a could be transmitted through a bus 109 d as depicted inFIG. 1c . Query 205 a could request a status of firmware operating inTRE 113, as well as other information such as an identity for primaryplatform 101 of PP-ID 101 i, versions of software or firmware supported,including an operating system, PBL identity or version, boot firmware121 versions, free memory capability, any attached transducers or radiosfor TRE 113 such as an NFC radio 113 z. Other configuration informationfor TRE 113 could be requested in a query 205 a. Query 205 a could alsobe referred to as a request or probe for TRE 113. The source of a query205 a could be device 102, or another server that device 102 connectswith, or an instruction received from IDS server 103. In general, aquery 205 a can be used to obtain information securely from a primaryplatform 101 regarding the configuration of primary platform 101.

Primary platform 101 could receive query 205 a and process the data orrequest. Primary platform 101 could respond with a message or response205 b which could comprise a response. As depicted in FIG. 2a , response205 b can include the identity for primary platform 101 of PP-ID 101 i,a selected set of cryptographic parameters 104 a, and a firmware status205 c. The selected set of cryptographic parameters 104 a could comprisea subset of the cryptographic parameters 104, such as an exemplary rowof data in FIG. 4 below. A query 205 a could also request or specify theselected set of cryptographic parameters 104 a, or include a list ofoptions for values in FIG. 4 and PP 101 could select the optionssupported and include parameters 104 a in response 205 c. Firmwarestatus 205 c can comprise information about firmware within PP 101, suchas a firmware version, a firmware installation date, a firmware size, anidentity for a firmware key 106 a associated with the firmware, a listof all installed firmware 106 stored by PP 101, a list of free oravailable memory, a log file or error log regarding the installation oroperation of a firmware 106, and other possibilities exist as well.

In addition, a firmware status 205 c could include information about ahost environment operated by TRE 113 such as a virtual machine versionor technology, an identity for a processor 113 b of TRE 113 which couldcomprise a CPUID, a host platform version equivalent to Virtualbox,VMware, etc. In general, a firmware status 205 c and response 205 b caninclude information for an IDS server 103 to utilize for selecting afirmware 106 for transfer to PP 101. Message 205 b can also include anidentity for IDS server 103, such as a domain name or IP address, whichcould be recorded in TRE 113 before a step 205 a.

Device 102 and server 103 may establish a secure session 108, whichcould comprise establishing a secure communications link between the twonodes using protocols such as TLS, IPSec, a virtual private network(VPN), a secure shell (SSH), or similar networking, transport, orapplication layer technologies in order to establish securecommunications between device 102 and server 103. Secure session 108 canutilize certificates for the two nodes in order to provide mutualauthentication and mutual key derivation for a symmetric encryption keyfor secure session 108. As depicted in FIG. 2a , the certificates couldcomprise a first certificate 103 t for server 103 and a secondcertificate 102 t for device 102. Device 102 and secure session library102 y could use a domain name for IDS server 103 received from TRE 113in a response 205 b.

In message 205 d, device 102 could use secure session 108 to send dataregarding primary platform 101, where the data regarding primaryplatform 101 can comprise the information received by a device driver102 g such as PBL and PP agent 102 x in response 205 c. Message 205 dcan include the identity of primary platform 101 of PP-ID 101 i, theselected set of cryptographic parameters 104 a, and also the firmwarestatus 205 c. For some exemplary embodiments, message 205 d could alsoinclude the certificate for PP 101 of PP certificate 120, where PPcertificate 120 can include the identity of primary platform of PP-ID101 i as depicted in FIG. 1b . Other summary or configuration data forPP 101 could be send in a message 205 d as well, such as a host platformversion operated by processor 113 b in TRE 113 (e.g. a host for avirtual machine like Virtualbox), etc. Note that processor 113 b in TRE113 could be a host operating a Xinu embedded operating system, andother possibilities exist as well.

In step 206 a, server 103 can receive message 205 d and process thedata. Server can use data within message 205 d to query or select datato determine an updated or available firmware 106 can be installed onprimary platform 101. Server 103 could use PP-ID 101 i and firmwarestatus 205 c to determine if a compatible firmware 106 is available. Asone example, server 103 could evaluate if (X) a version number for anexisting firmware 116 running or stored in TRE 113 has (Y) an updatedfirmware version available, such as with security patches, new features,support for new protocol versions, etc. Other possibilities exist aswell for a server 103 to evaluate or determine that a firmware 106 isavailable for a device 102 with a PP 101 and PP-ID 101 i from a message205 d without departing from the scope of the present disclosure. As oneexample, PP 101 may boot without a firmware 106 and firmware 116, andmessage 205 d could be a signal or request to download firmware 106 forPP 101. A step 206 a may also conclude with IDS server 103 determiningthat an image maker 299 may record a firmware 106 for device 102 with PP101.

At step 206 b, server 103 can use parameters 104 a and PP-ID 101 i toselect a set of IDS static PM keys, where the selected PM keys cancomprise the secret key SKIDS' 103 a and the corresponding public keyPK.IDS1 103 b as depicted and described in connection with FIG. 1a . Inother words, IDS server 103 could record a plurality of these keys (suchas different keys supporting different sets of cryptographic parameters104 a), and IDS server 103 can select the appropriate PM keys usingparameters 104 a. Further, IDS server 103 could have a plurality ofdifferent keys SK.IDS1 103 a for use with different PP 101, andconsequently select the correct SK.IDS1 103 a based on the identityPP-ID 101 i. In other words, IDS server 103 could use a first SK.IDS1103 a with a first set of PP 101 and a second SK.IDS1 103 a with asecond set of PP 101. IDS server 103 could also calculate a secure hashvalue for the selected, corresponding public key PK.IDS1 103 b in a step206 b.

IDS server 103 can then send image maker 299 a message 206 c via securesession 203 d. Message 206 c can include an identity of PP 101 of PP-ID101 i, related information regarding a firmware 106 such as a versionnumber received in firmware status 205 c, and message 206 c can comprisea query or request for firmware 106. At step 206 d, image maker 299 canreceive message 206 c via secure session 203 d and process the message.Image maker 299 can use information or data in message 206 c in order toselect a ciphertext firmware 106* and a corresponding firmware key 106 aused to encrypt the plaintext firmware 106. Image maker 299 could use anidentity of primary platform PP-ID 101 i to select the ciphertextfirmware 106* and the corresponding firmware key 106 a. Or, image maker299 could use other data in message 206 c to select ciphertext firmware106* and firmware key 106 a, such as a version of TRE 113, a version ofprimary platform boot firmware 121, a PP boot firmware configurationversion for PP boot configuration 123, cryptographic parameter 104, orrelated data as well for TRE 113. In some embodiments, an image maker299 could conduct a step 203 c after receiving a message 206 c. Thecollection of ciphertext firmware 106* and firmware key 106 a in a step206 d and a subsequent message 206 e can comprise an unbound image forTRE 113 and PP 101 and an unbound image for TRE 113 and PP 101 cancomprise an image for multiple different TRE 113 in different devices102.

Image maker 299 can then send IDS server 103 a message 206 e throughsecure session 203 d, where message 206 e includes the unbound imagecomprising at least a plaintext firmware key 106 a and the ciphertextfirmware 106*. IDS server 103 can receive message 206 e with the unboundimage and securely record or store the plaintext firmware key 106 a andthe ciphertext firmware 106*, while also using PP-ID 101 i to recordthat the unbound image is for device 102 with TRE 113 and PP 101.Although not depicted in FIG. 2a , IDS server 103 could also conduct avalidation check for the unbound image received in message 206 e, suchas verifying the plaintext firmware key 106 a properly decrypts theciphertext firmware 106* and that a resulting, calculated MAC code fromusing a MAC key from firmware key 106 a matches or is equal to thereceived MAC code for ciphertext firmware 106*. In this manner, and forother descriptions of decrypting firmware or a ciphertext ascontemplated herein, the decryption can include using a MAC key as partof a ciphering key in order to (i) calculate a MAC code for theciphertext, and (ii) compare the calculated MAC code with a received MACcode for the ciphertext in order to confirm the integrity of theciphertext (e.g. no bit errors or alteration of the ciphertext).

IDS server 103 can then calculate a secure hash over server staticpublic key comprising PK.IDS1 103 b, where the server static public keyPP.IDS1 103 b for PP 101 was selected in a step 206 b above. The securehash algorithm could be specified in a set of selected cryptographicparameters 104 a, such as the exemplary secure hash algorithms in FIG. 4below. An exemplary secure hash algorithm could comprise an SHA-2 orSHA-3 hash with an exemplary number of bits of 256, although otherpossibilities exist as well. The output of a secure hash over PK.IDS1103 b can comprise the value H(PK.IDS1) 207 a.

IDS server 103 can then send device 102 at least the secure hash value207 a via secure session 108 as a message 207 b. Note that the securehash value 207 a is included as an encrypted datagram within securesession 108. Although the use of a secure hash value 207 a instead ofthe plaintext value of PK.IDS1 103 b is depicted in FIG. 2a for message207 b, in other embodiments a server 103 could send the plaintext valueof PK.IDS1 103 b in a message 207 b instead of the hash value. For theseother embodiments, PK.IDS1 103 b may not be previously recorded in TRE113 and for these embodiments then (i) PK.IDS1 103 b could be includedin a certificate, where the digital signature for the certificate couldbe verified by PP 101 using a CA public key 131, and (ii) message 207 bcould include a certificate chain of intermediate certificates betweenthe certificate with PK.IDS1 103 b and CA public key 131 stored with PP101.

Device 102 could receive message 207 b with the secure hash ofH(PK.IDS1) 207 a using the secure session library 102 y. Device 102 canthen send TRE 113 the secure hash of H(PK.IDS1) 207 a in a message 207c, where message 207 c is sent using a device driver such as PBL and PPagent 102 x. In step 208, PP 101 operating in TRE 113 can receivemessage 207 c with the secure hash of H(PK.IDS1) 207 a and process thedata. In a step 208, PP 101 can conduct the secure hash algorithmspecified by cryptographic parameters 104 a over recorded public PM keysfor a plurality of IDS server static public keys 103 p in order to finda matching IDS server static public key 103 b. In other words, PP 101can select the IDS server static public key 103 b used by server 103based on the matching and/or equal secure hash value received in amessage 207 c. In this manner, PP 101 can identify and select the serverstatic public key 103 b used by server 103 since a calculated securehash value over keys in the set of public keys 103 p would match thereceived value of H(PK.IDS1) 207 a. In this manner, the value of PK.IDS1103 b does not need to be transmitted or received by TRE 113 and the keycan be identified by using H(PK.IDS1) 207 a. A benefit of usingH(PK.IDS1) 207 a instead of PK.IDS1 103 b is that device 102 couldinclude insecure components or processes.

For other exemplary embodiments of a step 208 and a message 207 c, themessage 207 c could include the plaintext value of PK.IDS1 103 b in theform of a certificate with a digital signature from a certificateauthority (and likewise message 207 b could include PK.IDS1 103 binstead of H(PK.IDS1)). For these embodiments, a step 208 could compriseverifying the digital signature for the certificate with PK.IDS1 103 busing certificate authority public keys 131 and a set of cryptographicparameters 104 within the certificate.

A step 208 can also include PP 101 selecting a one-time PM key pair fromPP one-time PM keys 101 e, where the selected PM key pair are compatiblewith the selected set of cryptographic parameters 104 a (such as usingthe named ECC curve in parameters 104 a). For some embodiments, PP 101could derive a private key using a random number generator 128 and theselected set of cryptographic parameters 104 a in order to obtain a PPone-time private key of SK-OT1.PP 101 c-1 and the corresponding one-timepublic key of PK-OT1.PP 101 d-1. In either case (deriving the PM keys orselecting the PM keys from a set of PP one-time PM keys 101 e), at theconclusion of a step 208, PP 101 can store one-time PM keys forsubsequent operations, where the one-time PM keys comprise at least ofSK-OT1.PP 101 c-1 and the corresponding one-time public key of PK-OT1.PP101 d-1. Note that if a previous pair of one-time PM keys in keys 101 ehad already been used for a previous download of ciphertext firmware106*, then the previous pair of one-time PM keys could be deprecated,and PP 101 could select a subsequent pair of one-time PM keys such asSK-OT2.PP 101 c-2 with PK-OT2.PP 101 d-2, etc.

Continuing in a step 208, PP 101 can then calculate a secure hash overPP static public key comprising PK-static.PP 101 b. The secure hashalgorithm could be specified in a set of selected cryptographicparameters 104 a, such as the exemplary secure hash algorithms in FIG. 4below. An exemplary secure hash algorithm could comprise an SHA-2 orSHA-3 hash with an exemplary number of bits of 256, although otherpossibilities exist as well. The output of a secure hash overPK-static.PP 101 b can comprise the value H(PK-static.PP) 208 a. Forsome exemplary embodiments, a secure hash value over PK-static.PP 101 bcould be omitted, and the value of PK-static.PP 101 b could be used forsubsequent messages in FIG. 2a instead of the secure hash valueH(PK-static.PP) 208 a. A step 208 can also include PP 101 using ahardware random number generator 128 in order to generate or derive arandom number 208 b.

PP 101 can then send PBL and PP agent 102 x in device 102 a message 209,where message 209 includes at least (i) the value H(PK-static.PP) 208 aand (ii) the primary platform one-time public key of PP-OT1.PP 101 d-1from a step 208 and (iii) the random number 208 b. In exemplaryembodiments in order to enhance security, PP 101 does not sendinformation for PK-static.PP 101 b until after a step 208, where PP 101can either (i) verify that H(PK.IDS1) 207 a matches a hash value for arecorded IDS public key in keys 103 p or (ii) verify that a receivedPK.IDS1 103 b with a certificate is properly signed and verified with aCA public key 131. For other embodiments that require a lower level ofsecurity, then PP 101 could send information for PK-static.PP 101 b atan earlier time than step 208, such as sending either (i) the valueH(PK-static.PP) 208 a with a message 205 b or (ii) a certificate thatincludes PK-static.PP 101 b with a message 205 b. Device 102 then usingsecure session library 102 y can send IDS server 103 a message 210 oversecure session 108, where message 210 includes the secure hash valueH(PK-static.PP) 208 a and the primary platform one-time public key ofPP-OT1.PP 101 d-1 and the random number 208 b.

Server 103 can receive message 210 and process the message. For a step211, where message 210 includes value H(PK-static.PP) 208 a, server 103can calculate a secure hash algorithm over primary platform staticpublic keys PK-static.PP 101 b recorded in a database 103 d in order tofind a matching primary platform static public key PK-static.PP 101 b.Note that the calculation of hash values over public keys in a database103 d could be performed one time or periodically as new public keys areinserted into database 103 d, instead of being calculated each time. Fora step 211, where message 210 includes a certificate for primaryplatform public key PK-static.PP 101 b, server 103 can verify a digitalsignature for the key PK-static.PP 101 b from a certificate authority.As contemplated herein, the term “certificate” can include both a publickey and a digital signature for the public key from a certificateauthority, such as with an X-509 v3 certificate. In addition for a step211, if server 103 does not record or store a value for PK-static.PP 101b after receipt of a message 210, then server 103 could query a TREmanufacturer using identity PP-ID 101 i (or H(PK-static.PP) 208 a) inorder to obtain the PP public key PK-static.PP 101 b. At the conclusionof a step 211, server 103 can select and store the value of PK-static.PP101 b for PP 101, where PP 101 can operate with an identity PP-ID 101 i.

At step 212, server 103 can conduct a key validation step for theprimary platform one-time public key of PP-OT1.PP 101 d-1. Server 103can verify that PK-OT1.PP 101 d-1 is not reused and has not beenreceived before by server 103, thereby increasing assurance thatsubsequent key exchanges such as key exchange 110 a is resistant toreplay attacks. In addition, for a step 212, server 103 can conductpublic key validation step to ensure that received primary platformone-time public key of PP-OT1.PP 101 d-1 is properly formatted and doesnot contain weak or compromising cryptographic data. For example, a step212 could comprise server 103 performing the steps for an ECC FullPublic-Key Validation Routine in section 5.6.2.3.2 of FIPS publicationSP 800-56A (revision 2). Alternatively, step 212 can comprise server 103performing the steps ECC Partial Public-Key Validation Routine insection 5.6.2.3.3 of the same FIPS publication. Other example stepswithin a public key validation step 212 can comprise (i) verifying thepublic key is not at the “point of infinity”, and (ii) verifying thecoordinates of the point for the public key are in the range [0, p−1],where p is the prime defining the finite field. Other possibilitiesexist as well for evaluating and validating a received public key iscryptographically secure in a public key validation step 212, withoutdeparting from the scope of the present disclosure. As contemplated inthe present disclosure, a server 103 or PP 101 can conduct a public keyvalidation step such as a step 212 each time a public key is received.

At step 103 e′, server 101 can generate or derive IDS one-time PM keys103 e, where IDS one-time PM keys 103 e are also depicted and describedin connection with FIG. 1a above. Although IDS one-time PM keys 103 eare described as “one-time” in exemplary embodiments the keys 103 e fora step 103 e′ could be one-time for a specific device 102 and couldpotentially be re-used with another device 103. In other words, as aminimum for exemplary embodiments, the IDS one-time PM keys 103 e wouldbe one-time keys for a specific device 102. The one-time PM keys 103 ecan also be referred to as “ephemeral” or “protocol” keys. A server 103can use a random number generator and a key pair generation algorithmwith the selected set of cryptographic parameters 104 a in order togenerate and store a server one-time secret key of SK-OT1.IDS1 103 c-1and the corresponding one-time public key of PK-OT1.IDS1 103 d-1 for usewith PP 101 at the conclusion of a step 103 e′.

IDS server 103 can then conduct a key exchange step 110 a. Details andexemplary data for a key exchange step 110 a by server 103 are depictedand described in connection with FIG. 2b below. In summary, IDS server103 can input at least (i) PP static public key PK-static.PP 101 b, (ii)PP one-time public key PK-OT1.PP 101 d-1, (iii) server static private(or secret) key SK-IDS1 103 a, (iv) and server one-time private keySK-OT1.IDS1 103 c-1, and (v) cryptographic parameters 104 a into a keyexchange 110 a in order to generate, calculate, or derive at least amutually derived symmetric ciphering key 218 a.

In exemplary embodiments, a key exchange step 110 a could also derive aMAC key 218 b. Server 103 could conduct an ECC point addition operationover (i) PK-static.PP 101 b, (ii) PK-OT1.PP 101 d-1 and input theresulting point into an ECDH key exchange algorithm 215 (shown in FIG.2b below). Server 103 could calculate a sum over (iii) SK-IDS1 103 b and(iv) SK-OT1.IDS1 103 c-1 and then calculate the modulus of the sum usingthe value n, where the value n can be defined or determined based uponthe selected set of cryptographic parameters 104 a. The modulus can thenalso be input into the ECDH key exchange algorithm as well in order toderive a mutually shared secret. The shared secret can be processed witha key derivation function (KDF) in order to obtain the mutually derivedsymmetric ciphering key 218 a. Note that additional steps 213-217 can beincluded in a key exchange step 110 a, and these additional steps213-217 are depicted and described in connection with FIG. 2b below.

After deriving a mutually shared symmetric ciphering key 218 a in a keyexchange step 110 a, server 103 can conduct an encryption step 111 ofthe plaintext firmware key 106 a and the random number 208 b, whererandom number 208 b was received in a message 210. Encryption step 111can also be referred to as a key encryption step, or the encryption of aSSD keys container using session keys. In other words, a mutuallyderived symmetric ciphering key 218 a can comprise a session key ascontemplated by the GSMA PP Requirements document. The plaintextfirmware key 106 a can be received by server 103 from an image maker 299in a message 206 e above. An encryption step 111 of the plaintextfirmware key 106 a in order to process or output a ciphertext firmwarekey 106 a* is depicted and described in connection with FIG. 2b below.As depicted in FIG. 2a , the ciphertext firmware key 106 a* can alsoinclude the random number 208 b in addition to the encrypted firmwarekey 106 a. The collection of a ciphertext firmware key 106 a* andciphertext firmware 106* can be referred to as a bound image 114 or a“bound package”.

The term “bound” can mean that the resulting data in the image orpackage is specifically written or structured for PP 101 on device 102(holding at least private key SK-static.PP 101 a), and another PP 101 ona different device 102 (or any other node on the Internet 107) would notbe feasibly able to read the bound image 114. Note that IDS one-timepublic key PK-OT1.IDS1 101 d-1 can also be included in a bound image 114or bound package. An unbound image can be used with an of a number ofdifferent devices 102 with PP 101 before the key exchange step 110 a andencryption step 111 over the firmware key 106 a. In addition, althoughnot depicted in FIG. 2b below, a symmetric ciphering key 218 a couldalso be used directly by IDS sever 103 to encrypt a plaintext firmware106 to create a ciphertext firmware 106*, and for these embodiments theuse of a separate firmware key 106 a and ciphertext firmware key 106 a*could be omitted. For these embodiments that omit the use of a separatefirmware key 106 a, a bound image 114 can comprise the ciphertextfirmware 106* and the IDS one-time public key PK-OT1.IDS1 101 d-1. Someplaintext metadata (including a file name, date, version, MAC code,initialization vector, etc.) can be included in a bound image 114.

After an encryption step 111 to encrypt a portion of bound image 114(either to create a ciphertext firmware key 106 a* or to directlyencrypt firmware 106 into ciphertext firmware 106*), IDS server 103 cansend device 102 a message 219 through secure session 108. Message 219can include the IDS one-time public key PK-OT1.IDS1 101 d-1 used with akey exchange 110 a and a ciphertext firmware key 106 a* from anencryption step 111, as well as ciphertext firmware 106*. The depictionof “{ }” for message 219 in FIG. 2a depicts that (i) ciphertext firmwarekey 106* can be encrypted using the mutually derived symmetric cipheringkey 218 a, and (ii) the mutually derived symmetric ciphering key 218 ais not normally transmitted in message 219 or from IDS server 103 todevice 102. Note that secure session 108 can provide an additional layerof encryption of both ciphertext firmware key 106 a* and ciphertextfirmware 106* though the authenticated and encrypted secure session 108.Also note that the data within the secure channel is transmitted asciphertext or encrypted data, since components in device 102 other thanTRE 113 may be insecure, and thus software operating within an operatingsystem 102 h for device 102 could normally read data from a securesession 108 after the first level of decryption from secure session 108.In this manner, only a TRE 113 with a PP 101 could read the plaintext ofa ciphertext firmware key 106 a* and ciphertext firmware 106*.

Device 102 using secure session library 102 y can receive message 210and remove the first layer of encryption from secure session 108 usingstandard libraries such as for TLS, DTLS, IPsec, or similar protocolsfor establishing a secure session. The resulting “plaintext” afterremoving the first level of encryption can comprise ciphertext firmwarekey 106 a* and ciphertext firmware 106*, as well as a plaintext valuefor server one-time public key PK-OT1.IDS1 103 d-1. In other words,device 102 can receive and read the bound image 114. Device 102 can thenconduct a step 220 to write bound image 114 to device nonvolatile memory102 s, which is also depicted and described in connection with FIG. 1cabove. Recording bound image 114 in device nonvolatile memory 102 s canremain secure, since only TRE 113 with PP 101 could feasibly decrypt thebound image 114. As depicted in FIG. 2a and also FIG. 1c above, boundimage 114 received in a message 219 can comprise server one-time publickey PK-OT1.IDS1 103 d-1, ciphertext firmware key 106 a*, and ciphertextfirmware 106*.

Device 102 can then use PBL and PP agent 102 x to write the data forbound image 114 from memory 102 s to TRE 113 and PP 101 via a message221. As contemplate herein, a message such as message 221 could compriseseparate parts, datagrams, blocks, or segments of data transmitted, andthe collection of separate parts, datagrams, blocks, or segments cancomprise the message. As depicted in FIG. 2a , a message 221 cancomprise at least the server one-time public key PK-OT1.IDS1 103 d-1,ciphertext firmware key 106 a*, and ciphertext firmware 106*. PBL and PPagent 102 x can operate in a secure manner, such as within a trustedexecution environment (TEE) operating within device 102, and PBL and PPagent 102 x can use a bus 109 d in order to communicate with TRE 113.TRE 113 and PP 101 can receive the message 221 and conduct a series ofsteps in order to process the message 221.

At step 222, PP 101 can conduct a key validation step on server one-timepublic key PK-OT1.IDS1 103 d-1. The key validation step 222 can beequivalent to a key validation step 212 depicted and described above fora server 103 with PK-OT1.PP 101 d-1. Key validation step 222 can verifythat PK-OT1.IDS1 103 d-1 is a point on the ECC curve specified bycryptographic parameters 104 and also that the point is not the “pointat infinity”. Key validation step 222 by PP 101 can verify thatPK-OT1.IDS1 103 d-1 is not reused and has not been received before by PP101, thereby increasing assurance that subsequent key exchanges such askey exchange 110 b is resistant to replay attacks. For example, a step222 could comprise PP 101 performing the steps for an ECC FullPublic-Key Validation Routine in section 5.6.2.3.2 of FIPS publicationSP 800-56A (revision 2). Alternatively, step 222 can comprise PP 101performing the steps ECC Partial Public-Key Validation Routine insection 5.6.2.3.3 of the same FIPS publication. Other possibilitiesexist as well for evaluating and validating a received public key iscryptographically secure in a public key validation step 222, withoutdeparting from the scope of the present disclosure. Upon conclusion of akey validation step 222, PP 101 can accept and store server one-timepublic key PK-OT1.IDS1 103 d-1 for use in subsequent steps.

PP 101 can then conduct a key exchange step 110 b. Details and exemplarydata for a key exchange step 110 b by PP 101 are depicted and describedin connection with FIG. 2c below. In summary, PP 101 can input at least(i) server static public key PK-IDS1 103 b, (ii) server one-time publickey PK-OT1.IDS1 103 d-1, (iii) PP static private key SK-static.PP 101 a,(iv) PP one-time private key SK-OT1.PP 101 c-1, and (v) cryptographicparameters 104 a into a key exchange 110 b in order to generate,calculate, or derive at least a mutually derived symmetric ciphering key218 a. In exemplary embodiments, a key exchange step 110 b could alsoderive a MAC key 218 b. PP 101 could conduct an ECC point additionoperation over (i) PK-IDS1 103 b, (ii) PK-OT1.IDS1 103 d-1 and input theresulting point into an ECDH key exchange algorithm 215 (shown in FIG.2c below). PP 101 could calculate a sum over (iii) SK-static.PP 101 a,and (iv) SK-OT1.PP 101 c-1 and then calculate the modulus of the sumusing the value n, where the value n can be defined or determined basedupon the selected set of cryptographic parameters 104 a. The modulus canthen also be input into the ECDH key exchange algorithm as well in orderto derive a mutually shared secret. The shared secret can be processedwith a key derivation function (KDF) in order to obtain the mutuallyderived symmetric ciphering key 218 a. Note that additional steps 223,224, 215, 216, and 217 can be included in a key exchange step 110 b, andthese additional steps 223, 224, 215, 216, and 217 are depicted anddescribed in connection with FIG. 2c below.

PP 101 can then conduct a decryption step 112 a of ciphertext firmwarekey 106 a* in order to convert ciphertext firmware key 106 a* into aplaintext firmware key 106 a and also the plaintext random number 208 b.A decryption step 112 a for PP 101 is also depicted and described inconnection with FIG. 2c below. For a decryption step 112 a, PP 101 canuse at least the mutually derived symmetric ciphering key 218 a from akey exchange step 110 b above in order to decrypt the (i) ciphertextfirmware key 106 a* into a plaintext firmware key 106 a and (ii) theencrypted random number 208 b into a plaintext random number 208 b. PP101 can verify that the decrypted random number 208 b from a step 112 aequals the derived random number 208 b from a step 208 above, in orderto confirm that server 103 has received and used the random number 208 bin the creation of ciphertext firmware key 106 a*

PP 101 can then store the plaintext firmware key 106 a for use in adecryption step 112 b below over ciphertext firmware 106*. Forembodiments where ciphertext firmware 106* is encrypted by server 103using the mutually derived symmetric ciphering key 218 a, then adecryption step 112 a and the use of a separate firmware key 106 a in abound image 114 could be omitted. In other words, for embodiments whereciphertext firmware 106* is encrypted by server 103 using the mutuallyderived symmetric ciphering key 218 a, then firmware key 106 a couldcomprise the mutually derived symmetric ciphering key 218 a, and thetransmission of a ciphertext firmware key 106 a* in message 219 andmessage 221 could be omitted.

PP 101 can then conduct a decryption step 112 b of ciphertext firmware106* using the plaintext firmware key 106 a, where the plaintextfirmware key 106 a could be read and stored by PP 101 in a step 112 aabove. A decryption step 112 b can convert the ciphertext firmware 106*into a plaintext firmware 106, which can subsequently be read, stored,and loaded into memory of PP 101. A decryption step 112 b for PP 101 isalso depicted and described in connection with FIG. 2c below. Note thatplaintext firmware key 106 a can include both a symmetric ciphering keyand a MAC key. The symmetric ciphering key can be used for decryptionand the MAC key can be used to verify data integrity (via comparing areceived MAC code with a calculated MAC code), such as detecting biterrors or flipped bits in the received ciphertext firmware 106*. A MACcode and an initialization vector could be included in plaintextmetadata received along with ciphertext firmware 106*. In some exemplaryembodiments, the use of a MAC key within plaintext firmware key 106 acould be omitted, and algorithms such as AES-SIV (e.g. with syntheticinitialization vectors) could be used for detecting data integrity.

PP 101 can then conduct a step 225 in order to load plaintext firmware106 and begin operating with the firmware 106. PP 101 could operate withconfiguration rules or logic that may be included in any of plaintextfirmware 106, metadata for plaintext firmware 106, or PP bootconfiguration 123 in order to specify parameters or values for loadingand operating with firmware 106. Firmware 106 could be associated withrules for PP 101 to operate firmware 106 as an image or “virtualmachine” in PP 101 (where PP 101 using boot firmware 121 can operate asthe host), including, but not limited to, a maximum amount of RAM 113 ememory allocated, a maximum amount of nonvolatile memory iNVM 113 sallocated, a maximum lifetime for firmware 106, a maximum number ofsupported or concurrent different firmware 106 that a PP 101 couldoperate at the same time, and other similar parameters as well.

In exemplary embodiments a step 225 can comprise PP 101 storingplaintext firmware 225 in RAM memory 101 e, as depicted in FIG. 1cabove. Note that RAM memory 101 e could comprise a nonvolatile RAMmemory or a persistent memory as well. A step 225 could also comprise acheck or verification that firmware 106 properly loads and operateswithin PP 101, including with any parameters or security specificationsfor the firmware 106 or PP 101. Upon successful verification thatfirmware 106 loads and operates within PP 101, PP 101 could thendeprecate or delete the PP one-time PM keys 101 e as well as deprecatethe IDS server 103 one-time public key PK-OT1.IDS1 103 d-1. In exemplaryembodiments, PP 101 continues to record or store PK-OT1.IDS1 103 d-1 iniNVM 113 s after a step 225 in order for PP 101 to conduct a subsequentkey validation step 222 on PK-OT1.IDS1 103 d-1, in order to determinethat PK-OT1.IDS1 103 d-1 is not used again at a later time. At theconclusion of a step 225, PP 101 can begin operating with the firmware106.

Note that firmware 106 operating in PP 101 can support applicationsrunning as device programs 102 i in device 102, such as the exemplaryapplications of mobile payments, identification and authentication ofdevice 102, secure key generation and storage for device 102, and otherapplications for device 102 using a firmware 106 in PP 101 exist as wellwithout departing from the scope of the present disclosure. In otherwords, firmware 106 in PP 101 can provide a cryptographically secureplatform for device 102 and may also operate as a “Smart SecurePlatform” according to the ETSI 5G series of standards, including aniSSP, an eSSP, and/or a rSSP. From some embodiments, firmware 106 couldoperate as an embedded SIM or eUICC according to the GSMA series ofstandards for embedded SIMs.

After a step 225, PP 101 can then send PBL and PP agent 102 x a message226 a, where message 226 a can be a signal that PP 101 has successfullyloaded plaintext firmware 106 and can operate with firmware 106. Message226 a can also include an updated firmware status 205 c′, which can besimilar to a firmware status 205 c above in message 205 c, except withupdated information for PP 101 that includes data regarding the firmware106 which was loaded in a step 225. In an exemplary embodiment, firmwarestatus 205 c′ can include the equivalent of an “OK” status or state forfirmware 106 operating or loaded within PP 101. PBL and PP agent 102 xcan receive and process the message 226 a from PP 101.

Device 102 can then use secure session library 102 y to send IDS server103 a message 226 b via secure session 108. Message 226 b can includethe updated firmware status 205 c′ received by PBL and PP agent 102 x inmessage 226 a above. IDS server 103 can receive message 226 b andconduct a step 227. IDS server 103 can store or record that firmware 106has been successfully loaded by PP 101. In a step 227, IDS server 103can also deprecate or delete the server one-time PM keys 103 e used in aFIG. 2a , in order to enhance forward secrecy. For embodiments wherefirmware status 205 c′ includes an error condition, such as firmware 106does not properly load in PP 101, then IDS server 103 at a step 227could conduct a subsequent series of steps to correct the errorcondition or error state. IDS server 103 could also notify other serversregarding the received firmware status 205 c′. As depicted in FIG. 2a ,IDS server 103 could send image maker 299 a message 227 a with updatedfirmware status 205 c′ or a subset of data within firmware status 205 c′that indicates the result or PP 101 loading and operating with thefirmware 106.

The exemplary embodiment depicted in FIG. 2a also supports a server 103generally encrypting a symmetric ciphering key for use by a device,where the device can (i) receive the encrypted symmetric ciphering key,(ii) conduct an ECDH key exchange with multiple PM key pairs, (iii)decrypt the encrypted symmetric ciphering key into a plaintext symmetricciphering key, and subsequently (iv) use the plaintext symmetricciphering key in order to decrypt a ciphertext. In other words, the useof an encrypted firmware with the symmetric ciphering key is notrequired in order to obtain the benefits of the technology disclosedherein. Thus, in some exemplary embodiments a primary platform 101 couldbe omitted and the ciphertext could comprise data other than anencrypted firmware 106*. The encrypted symmetric ciphering key couldcomprise an encrypted key 106 a* that could be used to decryptciphertext and the ciphertext does not need to be transferred from aserver 103 with the encrypted key 106 a*. As one example, the ciphertext106* could be received by a device 102 from a different server thanserver 103, although server 103 could also send a ciphertext 106*.

For these embodiments where server 103 sends device 102 an encryptedsymmetric key 106 a*, the server could record a server static privatekey 103 a and derive a server one-time private key 103 c. The servercould receive a device static public key 101 b and a device one-timepublic key 101 d. The server could conduct an ECDH key exchange step 110a from FIG. 2a and FIG. 2b below in order to mutually derive a secondsymmetric ciphering key K1 218 a, where device 102 could also mutuallyderive the second symmetric ciphering key K1 218 a with thecorresponding PM keys for those used by server 103 (such as the PM keysdepicted and described in connection with FIG. 2c ). The server 103could encrypt a plaintext symmetric key 106 a into the encryptedsymmetric key 106 a* using the mutually derived second symmetricciphering key K1 218 a. Thus, a symmetric key 106 a* could be usedgenerally by a device for decrypting ciphertext and the symmetric key106 a* could be used for other purposes than encrypting and decrypting afirmware 106. The server could send the encrypted symmetric key 106 a*to the device 102.

For these embodiments where server 103 sends device 102 an encryptedsymmetric key 106 a*, the device 102 could record a device staticprivate key 101 a and device a device one-time private key 101 c. Thedevice could receive or record a server static public key 103 b andreceive a server one-time public key 103 d. The device could conduct andECDH key exchange step 110 b from FIG. 2a and FIG. 2c in order tomutually derive the second symmetric ciphering key K1 218 a, where theserver 103 also mutually derived the key K1 218 a using thecorresponding PM keys for those used by device 102 (such as the PM keysdepicted and described in connection with FIG. 2b ). The device 102could decrypt an encrypted symmetric ciphering key 106 a* into aplaintext symmetric ciphering key 106 a using the mutually derived keyK1 218 a. The device 102 could subsequently decrypt a ciphertext usingthe plaintext symmetric ciphering key 106 a.

In addition, although FIGS. 2a through 2c depict a server encrypting asymmetric ciphering key 106 a into an encrypted symmetric ciphering key106 a*, the same static and one-time PM key pairs could be used by bothserver 103 and device 102 in order for (i) device 102 to encrypt asymmetric ciphering key 106 a into an encrypted symmetric ciphering key106 a* and (ii) server 103 to decrypt an encrypted symmetric cipheringkey 106 a* into a plaintext symmetric ciphering key 106 a. Server 103could then use the plaintext symmetric ciphering key 106 a to decrypt aciphertext received from device 102. In other words, device 102 couldconduct a step 110 b to derive key K1 218 a and then device 102 couldencrypt a plaintext key 106 a into encrypted key 106 a* using a step 203c (also depicted and described in FIG. 2b below), and then server 103could decrypt the encrypted key 106 a* into plaintext key 106 a using astep 112 a (also depicted and described in FIG. 2c below). Server 103could then use a step 112 b from FIG. 2c with the plaintext key 106 a todecrypt ciphertext into plaintext.

FIG. 2b

FIG. 2b is a flow chart illustrating exemplary steps for conducting akey exchange using PM keys in order to derive a shared secret key, forencrypting firmware with a firmware key, and for using the derivedshared secret key to encrypt the firmware key, in accordance withexemplary embodiments. Exemplary steps for a server 103 to mutuallyderive a shared secret X1 216 and symmetric key 218 a with PP 101 cancomprise a key exchange step 110 a. Exemplary steps in FIG. 2b for animage maker 299 to encrypt a plaintext firmware 106 using a firmware key106 a can comprise an encryption step 203 c. Exemplary steps in FIG. 2bfor a server 103 to encrypt a firmware key 106 a into a ciphertextfirmware key 106 a* can comprise an encryption step 111. The use of thesteps for a key exchange step 110 a, encryption step 203 c, andencryption step 111 were also depicted and described in connection withFIG. 2a above. Note that steps in FIG. 2b and the steps in FIG. 2c belowcan share some algorithms and values, and the descriptions for thealgorithms and values in FIG. 2b can be applicable for FIG. 2c . Forexample, the key exchange algorithm 215 in FIG. 2b can comprise an ECDHkey exchange equivalent to key exchange algorithm 215 in FIG. 2c (butwith different numbers input for the algorithm in the two differentFigures). The set of parameters 104 a depicted and described in FIG. 2bcan also be used in FIG. 2 c.

The processes and operations, described below with respect to all of thelogic flow diagrams and flow charts may include the manipulation ofsignals by a processor and the maintenance of these signals within datastructures resident in one or more memory storage devices. For thepurposes of this discussion, a process can be generally conceived to bea sequence of computer-executed steps leading to a desired result.

These steps usually require physical manipulations of physicalquantities. Usually, though not necessarily, these quantities take theform of electrical, magnetic, or optical signals capable of beingstored, transferred, combined, compared, or otherwise manipulated. It isconvention for those skilled in the art to refer to representations ofthese signals as bits, bytes, words, information, elements, symbols,characters, numbers, points, data, entries, objects, images, files, orthe like. It should be kept in mind, however, that these and similarterms are associated with appropriate physical quantities for computeroperations, and that these terms are merely conventional labels appliedto physical quantities that exist within and during operation of thecomputer.

It should also be understood that manipulations within the computer areoften referred to in terms such as listing, creating, adding,calculating, comparing, moving, receiving, determining, configuring,identifying, populating, loading, performing, executing, storing etc.that are often associated with manual operations performed by a humanoperator. The operations described herein can be machine operationsperformed in conjunction with various input provided by a human operatoror user that interacts with the device, wherein one function of thedevice can be a computer.

In addition, it should be understood that the programs, processes,methods, etc. described herein are not related or limited to anyparticular computer or apparatus. Rather, various types of generalpurpose machines may be used with the following process in accordancewith the teachings described herein.

The present disclosure may comprise a computer program or hardware or acombination thereof which embodies the functions described herein andillustrated in the appended flow charts. However, it should be apparentthat there could be many different ways of implementing the disclosurein computer programming or hardware design, and the disclosure shouldnot be construed as limited to any one set of computer programinstructions.

Further, a skilled programmer would be able to write such a computerprogram or identify the appropriate hardware circuits to implement thedisclosed disclosure without difficulty based on the flow charts andassociated description in the application text, for example. Therefore,disclosure of a particular set of program code instructions or detailedhardware devices is not considered necessary for an adequateunderstanding of how to make and use the disclosure. The inventivefunctionality of the claimed computer implemented processes will beexplained in more detail in the following description in conjunctionwith the remaining Figures illustrating other process flows.

Further, certain steps in the processes or process flow described in allof the logic flow diagrams below must naturally precede others for thepresent disclosure to function as described. However, the presentdisclosure is not limited to the order of the steps described if suchorder or sequence does not alter the functionality of the presentdisclosure. That is, it is recognized that some steps may be performedbefore, after, or in parallel other steps without departing from thescope and spirit of the present disclosure.

The processes, operations, and steps performed by the hardware andsoftware described in this document usually include the manipulation ofsignals by a CPU or remote server and the maintenance of these signalswithin data structures resident in one or more of the local or remotememory storage devices. Such data structures impose a physicalorganization upon the collection of data stored within a memory storagedevice and represent specific electrical or magnetic elements. Thesesymbolic representations are the means used by those skilled in the artof computer programming and computer construction to most effectivelyconvey teachings and discoveries to others skilled in the art.

Image maker 299 can conduct an encryption step 203 c, where the use foran encryption step 203 c is depicted and described in connection withFIG. 2a above. Plaintext can comprise the firmware 106 processed orgenerated by image maker in a step 203 b in FIG. 2a above. The firmwarekey 106 a for an encryption step 203 c can comprise a symmetricciphering key for encryption/decryption and also a MAC key. The firmwarekey 106 a can be input into a symmetric ciphering algorithm 230.Encryption step 203 c in FIG. 2b and decryption step 112 b in FIG. 2ccan use a common symmetric ciphering algorithm 230, which could comprisethe Advanced Encryption Standard with Synthetic Initialization Vectors(AES-SIV) (and deciphering algorithm) also with a common set ofsymmetric ciphering parameters 104 f from a set of cryptographicparameters 104. Note that initialization vector 232 can also be inputinto symmetric ciphering algorithm 230 for symmetric cipheringalgorithms 230 that utilize initialization vectors.

Other or different symmetric ciphering algorithms 230 besides AES-SIVcould be utilized as well, such as, but not limited to such as AES,Triple Data Encryption Standard (3DES), Blowfish, or related algorithms.Symmetric ciphering parameters 104 f can also specify the use of a blockchaining mode such as cipher block chaining (CBC), counter mode (CTR),or Galois/Counter mode (GCM) and other possibilities exist as well. Inaddition, symmetric ciphering parameters 104 f could specify a mode formessage authentication, which could comprise a CMAC mode as specified inNIST publication SP-800-38B. In some exemplary embodiments, a symmetricciphering algorithm 230 can comprise the AES-SIV algorithm as specifiedin IETF RFC 5297. The output from an encryption step 203 c using asymmetric ciphering algorithm 230 and the depicted values input can beciphertext firmware 106*, as depicted in FIG. 2b . The output from anencryption step 203 c using a symmetric ciphering algorithm 230 and thedepicted values input can also include MAC code 233, where MAC code 233can be used by the receiving party with a MAC key from firmware key 106a to verify message integrity. The initialization vector 232 can be sentalong with the ciphertext firmware 106* in order for both sides tocommonly initiate block chaining. In other words, a ciphertext firmware106* can include plaintext metadata for the ciphertext that includes aMAC code 233 and an initialization vector 232.

An IDS server 103 can conduct a key exchange step 110 a, and IDS server103 will be subsequently referred to as server 103 in this descriptionof FIG. 2b . Server 103 can conduct a step 213 to perform an ECC pointaddition operation on the (i) PP static public key PK-static.PP 101 b,(ii) PP one-time public key PK-OT1.PP 101 d-1 in order to obtain a pointon the elliptic curve defined by the selected subset of cryptographicparameters 104 a. Exemplary data for a step 213 will be shown below. Atstep 110 a, server 103 can also use a step 214 to calculate the sum of(iii) server static secret key SK-IDS1 103 a, (iv) and server one-timesecret key SK-OT1.IDS1 103 c-1, and then calculate the modulus of thesum using the value n, where the value n can be defined or determinedbased upon the selected set of cryptographic parameters 104 a. Exemplarydata for a step 214 will also be shown below.

The combination of output from step 213 and step 214 can be input can beinput into an ECDH key exchange algorithm 215 using parameters 104 a inorder to calculate the shared secret X1 216. Note that in some exemplaryembodiments, the use of a PP one time PM key pair 101 e could beomitted, which is depicted and described in connection with a step 301 ain FIG. 3 below, and for these embodiments then ECC point addition forstep 213 can be omitted and the public key input into an ECDH keyexchange algorithm 215 can comprise the single value for PK-static.PP101 b. In other words, a shared secret X1 216 can be calculated withoutrequiring a PP one-time public key for the embodiments in step 301 a(where private key SK-OT1.PP 101 c-1 would also be omitted from keyexchange calculations by PP 101 in a step 301 b), although the use of aPP one-time public key PK-OT1.PP 101 d-1 can be preferred for a step 213in other embodiments.

A summary of ECDH as a key exchange algorithm 215 is included in theWikipedia article titled “Elliptic Curve Diffie-Hellman” from Mar. 9,2018, which is herein incorporated by reference. An exemplary embodimentof key exchange algorithm 207 could comprise a “One-Pass Diffie-Hellman,C(1, 1, ECC CDH)” algorithm as described in section 6.2.2.2 on page 81of the National Institute of Standards and Technology (NIST) document“NIST SP 800-56A, Recommendation for Pair-Wise Key Establishment SchemesUsing Discrete Logarithm Cryptography” from March, 2007 which is herebyincorporated by reference its entirety. Other key exchange algorithms inNIST SP 800-56A could be utilized as well for a key exchange algorithm215 in FIG. 2b and FIG. 2c without departing from the scope of thepresent disclosure. Example calculations for an ECDH key exchange for akey exchange algorithm 215 are shown below. In exemplary embodiments,the key exchange algorithm 215 used by server 103 and PP 101 cancomprise the equivalent key exchange algorithm 215.

Other algorithms to derive a secret keys using public keys and privatekeys may also be utilized in a key exchange algorithm 215, such as, butnot limited to, the American National Standards Institute (ANSI)standard X-9.63. Cryptographic parameters 104 a can also includeinformation, values, or settings for conducting (i) a key exchangealgorithm 215 in step 110 a (and steps 110 b in FIG. 2c below) and (ii)a key derivation function 217 in order to derive a commonly sharedsymmetric encryption key K1 218 a. As contemplated herein, the terms“selected set of cryptographic parameters 104 a” and “cryptographicparameters 104 a”, and “parameters 104 a” can be equivalent, and canalso comprise a subset of exemplary cryptographic parameters depictedand described in connection with FIG. 4 below.

Parameters 104 a input into a key exchange algorithm 215 can include atime-to-live for a key K1 218 a that is derived, a supported pointformats extension, where the supported point formats extension couldcomprise uncompressed, compressed prime, or “compressed char2” formats,as specified in ANSI X-9.62 and related IETF standards. In other words,(i) an ECC keys input into a key exchange algorithm 215 and (ii) secretkeys output from key exchange algorithm 215 may have several differentformats and a set of parameters 104 a can be useful to specify theformat.

Exemplary data and numbers can be provided to demonstrate thecalculations for (i) ECC point addition step 213, (ii) step 214 tocombine private keys, and (iii) key exchange step 110 a. Parameters 104a can comprise the elliptic of “secp128r1” with key lengths of 128 bitlong keys. Although the exemplary numbers for keys, points, and a namedcurve are provided below, other values for keys, points, and named ECCcurves could be utilized as well. Other example named curves andparameters 104 a could comprise curve from IETF RFC 5480 and subsequentor related standards for ECDH key exchanges.

Although depicted and described herein as “ECC point addition”, theaddition operation can comprise simply an elliptic curve point additionoperation or calculation.

For a step 213, the PP static public key PK-static.PP 101 b can comprisethe exemplary values with X and Y numbers (or “coordinates”) of:

X: 94171534984237685678256585618241417039

Y: 203945269464835729838690547089813292056

Note that the PP static public key PK-static.PP 101 b corresponds to thePP static private key SK-static.PP 101 a from FIG. 2c below. The PPone-time public key PK-OT1.PP 101 d-1 can comprise the followingexemplary values with X and Y numbers (or “coordinates”) of:

X: 319423829544285733939020505180109110187

Y: 242179187598040154943588326777101424083

An ECC point addition 213 for a step 110 a with the above two keysPK-static.PP 101 b and PK-OT1.PP 101 d-1 will result in the followingexemplary point for input into an ECDH key exchange algorithm 215 in keyexchange step 110 a:

X: 15725052432774382840929761440274832589

Y: 217317805140710190286653933543727803288

The above combination of both PK-static.PP 101 b and PK-OT1.PP 101 d-1for a key exchange step 110 a via an ECC point addition 213 is depictedin FIG. 2b with the “+” symbol between the public keys.

The server one-time secret key SK-OT1.IDS1 103 c-1 can comprise theexemplary following number, and can be recorded in server 103 after akey pair generation step 103 e′ from FIG. 2a above:

330225223315954763304200471137380016969

The server static secret key SK-IDS1 103 a can comprise the exemplaryfollowing number, and can be recorded in server 103 before key pairgeneration step 103 e′, such as during initial configuration of server103 (such that the resulting public key PK-IDS1 103 b could be madeavailable to a manufacturer of TRE 113 for a step 202 in FIG. 2a ):

209122135174501513062984245101620420255

Note that the private keys SK-OT1.IDS1 103 c-1 and SK-IDS1 103 a abovecorrespond to the public keys PK-OT1.IDS1 103 d-1 and PK-IDS1 103 b usedby a PP 101 in FIG. 2c below.

Server 103 can conduct step 214 to calculate the sum of server staticsecret key SK-IDS1 103 a and the server one-time secret key SK-OT1.IDS1103 c-1, and then calculate the modulus of the sum using the value n,where the value n can be defined or determined based upon the selectedset of cryptographic parameters 104 a. For the exemplary values for keysabove, when using the named elliptic curve secp128r1, the value of n cancomprise the decimal number:

340282366762482138443322565580356624661

Consequently the modulus of (i) the sum of server static secret keySK-IDS1 103 a and the server one-time secret key SK-OT1.IDS1 103 c-1 and(ii) the value n above will equal the following number for a step 214:

199064991727974137923862150658643812563

The output of the above ECC point addition 213 for public keysPK-static.PP 101 b and PK-OT1.PP 101 d-1 can be input into ECDH keyexchange algorithm 215 using parameters 104 a. An ECDH key exchangealgorithm 215 in key exchange step 110 a can input (i) the pointcalculated above from the ECC point addition 213 on the public keys 101b and 101 d-1 and (ii) the value calculated from a step 214 (e.g. (103a+103 c-1) mod n). The output of ECDH key exchange algorithm 215 in keyexchange step 110 a can be the shared secret value or point X1 216. Notethat the secret X1 216 as derived by server 103 in a key exchange step110 a equals or is the same numeric value as the secret X1 216 derivedby PP 101 in a key derivation step 110 b below. An exemplary number orvalue for secret X1 216 calculated by server 103 using a key exchangestep 110 a and ECDH key exchange algorithm using the above exemplarynumeric values for (i) PP static public key PK-static.PP 101 b, (ii) PPone-time public key PK-OT1.PP 101 d-1, (iii) server static secret keySK-IDS1 103 a, and (iv) and server one-time secret key SK-OT1.IDS1 103c-1 would be:

X: 192457465648897421085529769283600671459

Y: 12614498480690967741828130967599964269

For a key exchange step 110 a, derived shared secret key X1 216 can beinput into a key derivation function 217 where the key derivationfunction 217 can be equivalent to the key derivation function 217depicted and described in connection with FIG. 2c below for a keyexchange step 110 b. Note that for key derivation steps in the presentdisclosure, the X coordinate of a derived shared secret can be taken orused as input into the key derivation function 217, although otherpossibilities exist as well. The output of a key derivation function 217can comprise both (i) a symmetric ciphering key K1 218 a and (ii) a MACkey 218 b. MAC key 218 b can be used with a symmetric cipheringalgorithm in order to generate a MAC code, such that the other partyusing the same key K1 218 a and MAC key 218 b can process the ciphertextand calculate the same MAC code 233 in order to verify messageintegrity. The use of key K1 218 a and MAC key 218 b are described inconnection with encryption step 203 c and decryption step 112 b.

Key derivation function 217 can use a secure hash algorithm such as, butnot limited to, SHA-256, SHA-384, SHA-3, etc. and additional values suchas a shared (between server 103 and PP 101) text string with secret X1216. The specification of a secure hash algorithm and the text stringfor use with a key derivation function 217 could be commonly sharedbetween server 103 and PP 101 by commonly shared parameters 104 a. Theoutput of a secure hash algorithm within a key derivation function 217could have a subset of bits selected or possibly a secure hash expandedin order to obtain the number of bits required for a symmetric key witha symmetric ciphering algorithm, such as key K1 218 a. A key derivationfunction (KDF) 217 could comprise a KDF compatible with or specified byANSI standards for “X9.63 Key Derivation Function”. Other possibilitiesexist for a key derivation function 217 to convert a secret X1 216 intoa symmetric ciphering key K1 218 a and a MAC key 218 b without departingfrom the scope of the present disclosure. As contemplated in the presentdisclosure, although an ECC key such as secret X1 216 can comprise acoordinate with an X value and a Y value, in exemplary embodiments asingle number comprising the X value can be selected and input into akey derivation function 217.

Server 103 can conduct an encryption step 111 of firmware key 106 a,where the use for an encryption step 111 is depicted and described inconnection with FIG. 2a above. Plaintext in a step 111 can comprise thefirmware key 106 a, where the firmware key 106 a can be received byserver 103 in a message 206 e in FIG. 2a , along with the ciphertextfirmware 106*. Although not depicted for a step 111 in FIG. 2b , other,additional data could be included in the plaintext for an encryptionstep 111, and as a minimum the plaintext for an encryption step 111includes a plaintext firmware key 106 a*. Or, in some exemplaryembodiments, an encryption step 203 c above could be omitted and server103 could receive plaintext firmware 106 and encrypt the plaintextfirmware 106 (instead of a plaintext firmware key 106 a) with key 218 ain order to generate a ciphertext 106*.

The symmetric ciphering key for encryption step 111 can comprisesymmetric key K1 218 a from a key exchange step 110 a above. Althoughnot depicted for an encryption step 111, a MAC key 218 b from step 110 acan be input into a symmetric ciphering algorithm 230 as well.Encryption step 111 in FIG. 2b and decryption step 112 a in FIG. 2c canuse a common symmetric ciphering algorithm 230, which could comprise theAdvanced Encryption Standard with Synthetic Initialization Vectors(AES-SIV) (and deciphering algorithm) also with a common set ofsymmetric ciphering parameters 104 f from a set of cryptographicparameters 104. Note that MAC key 218 b can also be input into symmetricciphering algorithm 230 along with an initialization vector 232 (asdepicted and described above for an encryption step 203 c).

Other or different symmetric ciphering algorithms 230 could be utilizedas well, such as, but not limited to such as AES, Triple Data EncryptionStandard (3DES), Blowfish, or related algorithms. Symmetric cipheringparameters 104 f can also specify the use of a block chaining mode suchas cipher block chaining (CBC), counter mode (CTR), or Galois/Countermode (GCM) and other possibilities exist as well. In addition, symmetricciphering parameters 104 f could specify a mode for messageauthentication, which could comprise a CMAC mode as specified in NISTpublication SP-800-38B. In some exemplary embodiments, a symmetricciphering algorithm 230 can comprise the AES-SIV algorithm as specifiedin IETF RFC 5297. The output from an encryption step 111 using asymmetric ciphering algorithm 230 and symmetric key 218 a and thedepicted values input can be ciphertext firmware key 106 a*, as depictedin FIG. 2 b.

As contemplated herein, an elliptic curve point addition operation couldalso be calculated after a scalar multiplication of the private keys inorder to mutually derive the shared secret. In other words, the point X1216 could also equal (i) a first point of {(PP static public keyPK-static.PP 101 b) multiplied by (the sum of server static secret keySK-IDS1 103 a and the server one-time secret key SK-OT1.IDS1 103 c-1 modn)} added to (ii) a second point of (PP one-time public key PK-OT1.PP101 d-1 multiplied by (the sum of server static secret key SK-IDS1 103 aand the server one-time secret key SK-OT1.IDS1 103 c-1 mod n)}. Thus,the shared secret X1 216 could be calculated from an elliptic curvepoint addition operation using PP static public key PK-static.PP 101 band PP one-time public key PK-OT1.PP 101 d-1. In other words, sharedsecret X1 216 can be calculated from two points and one point additionoperation over the two points, where the two points are determined usingat least PP static public key PK-static.PP 101 b and PP one-time publickey PK-OT1.PP 101 d-1.

Further, the same value of point X1 216 could be calculated as(PK-static.PP 101 b*SK-IDS1 103 a)+(PK-static.PP 101 b*SK-OT1.IDS1 103c-1)+(PK-OT1.PP 101 d-1*SK-IDS1 103 a)+(PK-OT1.PP 101 d-1*SK-OT1.IDS1103 c-1). Thus, a mutually derived shared secret could be calculated byserver 103 using at least one point addition operations and at least twopoints, where the at least two points are determined using at least PPstatic public key PK-static.PP 101 b and PP one-time public keyPK-OT1.PP 101 d-1. Note that a mutually derived point X1 216 ascalculated by server 103 could also use additional public keys for PP101 or additional public keys associated with PP 101, such as from adevice owner.

FIG. 2c

FIG. 2c is a flow chart illustrating exemplary steps for conducting akey exchange using PM keys in order to derive a shared secret key, fordecrypting a firmware key using the derived shared secret key, and fordecrypting firmware using the decrypted firmware key, in accordance withexemplary embodiments. Exemplary steps for a primary platform 101 tomutually derive a shared secret X1 216 and symmetric key 218 a withserver 103 can comprise a key exchange step 110 b. Exemplary steps for aPP 101 to decrypt a ciphertext firmware key 106 a* using the derivedsymmetric key 218 a can comprise a decryption step 112 a. Exemplarysteps for a PP 101 to decrypt a ciphertext firmware 106* using theplaintext firmware key 106 a can comprise a decryption step 112 b. Theuse of the steps for a key exchange step 110 b, decryption step 112 a,and decryption step 112 b were also depicted and described in connectionwith FIG. 2a above.

A PP 101 can conduct a key exchange step 110 b. PP 101 can conduct astep 223 to perform an ECC point addition operation on the (i) serverstatic public key PK-IDS1 103 b, and (ii) server one-time public keyPK-OT1.IDS1 103 d-1 in order to obtain a point on the elliptic curvedefined by the selected subset of cryptographic parameters 104 a.Exemplary data for a step 223 will be shown below. At step 110 b, PP 101can also use a step 224 to calculate the sum of (iii) PP static secretkey SK-static.PP 101 a, (iv) PP one-time secret key SK-OT1.PP 101 c-1,and then calculate the modulus of the sum using the value n, where thevalue n can be defined or determined based upon the selected set ofcryptographic parameters 104 a. Exemplary data for a step 224 will alsobe shown below.

The combination of output from step 223 and step 224 can be input can beinput into an ECDH key exchange algorithm 215 using parameters 104 a inorder to calculate the shared secret X1 216. Note that in some exemplaryembodiments, the use of a server one-time public key PK-OT1.IDS1 103 d-1could be omitted, which is depicted and described in connection with astep 309 b in FIG. 3 below, and for these embodiments then ECC pointaddition for step 223 can be omitted and the public key input into anECDH key exchange algorithm 215 can comprise the single value for serverstatic public key PK-IDS1 103 b. In other words, a shared secret X1 216can be calculated without requiring a server one-time public keyPK-OT1.IDS1 103 d-1 for the embodiments in step 309 b (where private keySK-OT1.IDS1 103 c-1 would also be omitted from key exchange calculationsby server 103 in a step 309 a), although the use of a IDS one-timepublic key PK-OT1.IDS1 103 d-1 can be preferred for a step 213 in otherembodiments.

Exemplary data and numbers can be provided to demonstrate thecalculations for (i) ECC point addition step 223, (ii) step 224 tocombine private keys, and (iii) key exchange step 110 b. Parameters 104a can comprise the elliptic of “secp128r1” with key lengths of 128 bitlong keys. Although the exemplary numbers for keys, points, and a namedcurve are provided below, other values for keys, points, and named ECCcurves could be utilized as well. Other example named curves andparameters 104 a could comprise curve from IETF RFC 5480 and subsequentor related standards for ECDH key exchanges.

The server one-time public key PK-OT1.IDS1 103 d-1 can comprise thefollowing exemplary values with X and Y numbers (or “coordinates”) of:

X: 239356896551017663412726672579682627094

Y: 209570745539973929739512070961905802250

Note that the above server one-time public key PK-OT1.IDS1 103 d-1corresponds to the server one-time private key SK-OT1.IDS1 103 c-1 abovefrom FIG. 2b . The server static public key PK-IDS1 103 b can comprisethe following exemplary values with X and Y numbers (or “coordinates”)of:

X: 203473426612520506812902270038827201196

Y: 64318327833120582836973711848343026891

Note that the above server static public key PK-IDS1 103 b correspondsto the server static private key SK-IDS1 103 a above from FIG. 2b . ECCpoint addition step 223 by PP 101 can combine the server one-time publickey PK-OT1.IDS1 103 d-1 and the server static public key PK-IDS1 103 bin order to output the following value input into ECDH key exchangealgorithm 215 in a step 110 b:

X: 59121922812458579600446751790662160796

Y: 304934509235778268978955867170200917057

The above combination of both server static public key PK-IDS1 103 b andserver one-time public key PK-OT1.IDS1 103 d-1 for a key exchange step110 b via an ECC point addition 223 is depicted in FIG. 2c with the “+”symbol between the public keys.

The PP static secret key SK-static.PP 101 a can comprise the exemplaryfollowing number, and can be recorded in PP 101:

221902394438765368991155818063875293908

The PP one-time secret key SK-OT1.PP 101 c-1 can comprise the exemplaryfollowing number, and can be recorded or stored by PP 101 in keys 101 e:

246768250079261690512638148137618184294

Note that the private keys SK-static.PP 101 a and PP one-time secret keySK-OT1.PP 101 c-1 above correspond to the public keys PK-static.PP 101 band PK-OT1.PP 101 d-1 used by a server 103 in FIG. 2b above.

PP 101 can conduct step 224 to calculate the sum of PP static secret keySK-static.PP 101 a and the PP one-time secret key SK-OT1.PP 101 c-1, andthen calculate the modulus of the sum using the value n, where the valuen can be defined or determined based upon the selected set ofcryptographic parameters 104 a. For the exemplary values for keys above,when using the named elliptic curve secp128r1, the value of n cancomprise the decimal number:

340282366762482138443322565580356624661

Consequently the modulus of (i) the sum of PP static secret keySK-static.PP 101 a and the PP one-time secret key SK-OT1.PP 101 c-1 and(ii) the value n above will equal the following number for a step 224:

128388277755544921060471400621136853541

The output of the above ECC point addition 223 for the server one-timepublic key PK-OT1.IDS1 103 d-1 and the server static public key PK-IDS1103 b can be input into ECDH key exchange algorithm 215 in a step 110 busing parameters 104 a. An ECDH key exchange algorithm 215 in keyexchange step 110 b can input (i) the point calculated above from theECC point addition 223 on the public keys 103 b and 103 d-1 and (ii) thevalue calculated from a step 224 (e.g. (101 a+101 c-1) mod n). Theoutput of ECDH key exchange algorithm 215 in key exchange step 110 b canbe the shared secret value or point X1 216. Note that the secret X1 216as derived by PP 101 in a key exchange step 110 b equals or is the samenumeric value as the secret X1 216 derived by server 103 in a keyexchange step 110 a above. An exemplary number or value for secret X1216 calculated by PP 101 using a key exchange step 110 b and ECDH keyexchange algorithm using the above exemplary numeric values for (i)server static public key PK-IDS1 103 b, and (ii) server one-time publickey PK-OT1.IDS1 103 d-1, (iii) PP static secret key SK-static.PP 101 a,and (iv) PP one-time secret key SK-OT1.PP 101 c-1 would be:

X: 192457465648897421085529769283600671459

Y: 12614498480690967741828130967599964269

As contemplated herein, an elliptic curve point addition operation couldalso be calculated after a scalar multiplication of the private keys inorder to mutually derive the shared secret. In other words, the point X1216 could also equal (i) a first point of {(server one-time public keyPK-OT1.IDS1 103 d-1) multiplied by (the sum of PP static secret keySK-static.PP 101 a and the PP one-time secret key SK-OT1.PP 101 c-1 modn)} added to (ii) a second point of (server static public keyPK-static.IDS1 103 b) multiplied by (the sum of PP static secret keySK-static.PP 101 a and the PP one-time secret key SK-OT1.PP 101 c-1 modn)}. Thus, the shared secret X1 216 could be calculated from an ellipticcurve point addition operation using server one-time public keyPK-OT1.IDS1 103 d-1 and server static public key PK-static.IDS1 103 b.In other words, shared secret X1 216 can be calculated from two pointsand one point addition operation over the two points, where the twopoints are determined using at least server static public keyPK-static.IDS1 103 b and server one-time public key PK-OT1.IDS1 103 d-1.

Further, the same value of point X1 216 could be calculated as(PK-static.IDS1 103 b*SK-static.PP 101 a)+(PK-static.IDS 103 b*SK-OT1.PP101 c-1)+(PK-OT1.IDS 103 d-1*SK-static.PP 101 a)+(PK-OT1.IDS 103d-1*SK-static.PP 101 a). Thus, a mutually derived shared secret could becalculated by PP 101 using at least one point addition operations and atleast two points, where the at least two points are determined using atleast IDS static public key PK-static.IDS1 103 b and IDS one-time publickey PK-OT1.IDS1 103 d-1. Note that a mutually derived point X1 216 ascalculated by PP 101 could also use additional public keys for server103 or a network or other servers associated with server 103.

For a key exchange step 110 b, derived shared secret key X1 216 can beinput into a key derivation function 217 where the key derivationfunction 217 can be equivalent to the key derivation function 217depicted and described in connection with FIG. 2b above for a keyexchange step 110 a. Note that for key derivation steps in the presentdisclosure, the X coordinate of a derived shared secret can be taken orused as input into the key derivation function 217, although otherpossibilities exist as well. The output of a key derivation function 217can comprise both (i) a symmetric ciphering key K1 218 a and (ii) a MACkey 218 b. MAC key 218 b can be used with a symmetric cipheringalgorithm in order to generate a MAC code 233, such that the other partyusing the same key K1 218 a and MAC key 218 b can process the ciphertextand calculate the same MAC code 233 in order to verify messageintegrity. The use of key K1 218 a and MAC key 218 b are described inconnection with encryption step 203 c and decryption step 112 b.

Key derivation function 217 can use a secure hash algorithm such as, butnot limited to, SHA-256, SHA-384, SHA-3, etc. and additional values suchas a shared (between server 103 and PP 101) text string with secret X1216. The specification of a secure hash algorithm and the text stringfor use with a key derivation function 217 could be commonly sharedbetween server 103 and PP 101 by commonly shared parameters 104 a. Theoutput of a secure hash algorithm within a key derivation function 217could have a subset of bits selected or possibly a secure hash expandedin order to obtain the number of bits required for a symmetric key witha symmetric ciphering algorithm, such as key K1 218 a. A key derivationfunction (KDF) 217 could comprise a KDF compatible with or specified byANSI standards for “X9.63 Key Derivation Function”. Other possibilitiesexist for a key derivation function 217 to convert a secret X1 216 intoa symmetric ciphering key K1 218 a and a MAC key 218 b without departingfrom the scope of the present disclosure. As contemplated in the presentdisclosure, although an ECC key such as secret X1 216 can comprise acoordinate with an X value and a Y value, in exemplary embodiments asingle number comprising the X value can be selected and input into akey derivation function 217.

PP 101 can conduct a decryption step 112 a of ciphertext firmware key106 a* and random number 208 b, where the use for a decryption step 112a is depicted and described in connection with FIG. 2a above. Althoughnot depicted for a step 112 a in FIG. 2c , other, additional data couldbe included as the ciphertext for a decryption step 112 a, and as aminimum the ciphertext for a decryption step 112 a includes a ciphertextfirmware key 106 a*. Ciphertext in a step 112 a can comprise theciphertext firmware key 106 a* and a ciphertext of random number 208 b,where the ciphertext firmware key 106 a* and ciphertext random number208 b can be received by PP 101 in a message 221 in FIG. 2a , along withthe ciphertext firmware 106*. Or, in some exemplary embodiments, adecryption step 112 a above could be omitted and PP 101 could receiveciphertext firmware 106* and decrypt the ciphertext firmware 106* usingsymmetric ciphering key 218 a (instead of a first decrypting ciphertextfirmware key 106 a*) in order to read a plaintext firmware 106.

The symmetric ciphering key for decryption step 112 a can comprisesymmetric key K1 218 a from a key exchange step 110 b above. Althoughnot depicted for a decryption step 112 a, a MAC key 218 b from step 110b can be input into a symmetric ciphering algorithm 230 as well.Decryption step 112 a in FIG. 2c and encryption step 111 in FIG. 2b canuse a common symmetric ciphering algorithm 230, which could comprise theAdvanced Encryption Standard with Synthetic Initialization Vectors(AES-SIV) (and deciphering algorithm) also with a common set ofsymmetric ciphering parameters 104 f from a set of cryptographicparameters 104. Note that MAC key 218 b can also be input into symmetricciphering algorithm 230 along with an initialization vector 232 (asdepicted and described above for an encryption step 203 c).

Other or different symmetric ciphering algorithms 230 could be utilizedas well, such as, but not limited to such as AES, Triple Data EncryptionStandard (3DES), Blowfish, or related algorithms. Symmetric cipheringparameters 104 f can also specify the use of a block chaining mode suchas cipher block chaining (CBC), counter mode (CTR), or Galois/Countermode (GCM) and other possibilities exist as well. In addition, symmetricciphering parameters 104 f could specify a mode for messageauthentication, which could comprise a CMAC mode as specified in NISTpublication SP-800-38B. In some exemplary embodiments, a symmetricciphering algorithm 230 can comprise the AES-SIV algorithm as specifiedin IETF RFC 5297. The output from a decryption step 112 a using asymmetric ciphering algorithm 230 and symmetric key 218 a and thedepicted values input can be plaintext firmware key 106 a and the randomnumber 208 b, as depicted in FIG. 2c . PP 101 can then compare therandom number 208 b from a decryption step 112 a with the random number208 b sent in a message 209 to verify the two values for random number208 b are equal (thereby increasing security). For some exemplaryembodiments, the use of a random number 208 b could be optionallyomitted.

PP 101 can then conduct a decryption step 112 b, where the use for adecryption step 112 b is depicted and described in connection with FIG.2a above. Ciphertext can comprise the ciphertext firmware 106* receivedby PP 101 in a message 221. The plaintext firmware key 106 a for adecryption step 112 a can comprise the firmware key 106 a decrypted in astep 112 a above. The firmware key 106 a can be input into a symmetricciphering algorithm 230. Decryption step 112 b in FIG. 2c and decryptionstep 203 c in FIG. 2b can use a common symmetric ciphering algorithm230, which could comprise the Advanced Encryption Standard withSynthetic Initialization Vectors (AES-SIV) (and deciphering algorithm)also with a common set of symmetric ciphering parameters 104 f from aset of cryptographic parameters 104. Note that initialization vector 232can also be input into symmetric ciphering algorithm 230 for symmetricciphering algorithms 230 that utilize initialization vectors.

The output from a decryption step 112 b using a symmetric cipheringalgorithm 230 and the depicted values input, including a plaintextfirmware key 106 a from step 112 a, can be plaintext firmware 106, asdepicted in FIG. 2c . The output from a decryption step 112 b using asymmetric ciphering algorithm 230 and the depicted values input can alsoinclude MAC code 233, where MAC code 233 can be used by the PP 101 witha MAC key from firmware key 106 a to verify message integrity. Theinitialization vector 232 can be sent along with the ciphertext firmware106* in order for both sides to commonly initiate block chaining. Inother words, a ciphertext firmware 106* can include plaintext metadatafor the ciphertext that includes a MAC code 233 and an initializationvector 232.

FIG. 3

FIG. 3 is a flow chart illustrating exemplary steps for conducting a keyexchange using PM keys in order to derive a shared secret key, inaccordance with exemplary embodiments. Although key exchange steps 110 aand 110 b depicted and described the use of one-time PM key pairs byboth PP 101 and IDS server 103, a key exchange step could omit the useof one-time PM keys by either PP 101 or IDS server 103. For a keyexchange step 301 a by IDS server 103 and a corresponding key exchangestep 301 b by PP 101, the use of PP one-time PM keys could be omitted.For these embodiments, an ECDH key exchange algorithm 215 for IDS server103 in a step 301 a could use (i) PP static public key PK-static.PP 101b, (ii) server static secret key SK-IDS1 103 a, and (iii) serverone-time secret key SK-OT1.IDS1 103 c-1. The corresponding ECDH keyexchange algorithm 215 for PP 101 in a step 301 b could use (i) serverstatic public key PK-IDS1 103 b, and (ii) server one-time public keyPK-OT1.IDS1 103 d-1, and (iii) PP static secret key SK-static.PP 101 a.The output of an ECDH key exchange algorithm 215 for both key exchangestep 301 a and 301 b can comprise a mutually derived shared secret keyX1 216 as depicted and described in connection with FIG. 2b and FIG. 2c. The exemplary calculations remain equivalent to the calculationsdepicted and described in connection with FIG. 2b and FIGS. 2c , exceptthe use of PP one-time PM keys 101 e could be omitted.

For a key exchange step 309 a by IDS server 103 and a corresponding keyexchange step 309 b by PP 101, the use of IDS one-time PM keys could beomitted. For these embodiments, an ECDH key exchange algorithm 215 forIDS server 103 in a step 309 a could use (i) PP static public keyPK-static.PP 101 b, (ii) server static secret key SK-IDS1 103 a, and(iii) PP one-time public key PK-OT1.PP 101 d-1. The corresponding ECDHkey exchange algorithm 215 for PP 101 in a step 309 b could use (i)server static public key PK-IDS1 103 b, and (ii) PP one-time secret keySK-OT1.PP 101 c-1, and (iii) PP static secret key SK-static.PP 101 a.The output of an ECDH key exchange algorithm 215 for both key exchangestep 309 a and 309 b can comprise a mutually derived shared secret keyX1 216 as depicted and described in connection with FIG. 2b and FIG. 2c. The exemplary calculations remain equivalent to the calculationsdepicted and described in connection with FIG. 2b and FIG. 2c , exceptthe use of IDS one-time PM keys 103 e could be omitted.

FIG. 4

FIG. 4 is an illustration of an exemplary set of cryptographicparameters, in accordance with exemplary embodiments. Cryptographicparameters 104 can specify sets of cryptographic parameters that aresupported by PP 101, server 103, and image maker 299 in order conductthe series of steps and message flows depicted in FIG. 2a , as well asother figures above. Cryptographic parameters 104 can be recorded innonvolatile memory in each of PP 101, server 103, and image maker 299.As depicted in FIG. 1a for server 103 and PP 101, nodes in a system 100or system 200 can record and operate with a set of cryptographicparameters 104. Cryptographic parameters 104 can record an identifiedcollection of cryptographic algorithms or specifications such as a setidentifier 104 a, a key length 104 b, an ECC curve name 104 c, a hashalgorithm 104 d, symmetric ciphering key length 104 e, settings for asymmetric ciphering algorithm 104 f, and a random number length 104 g.

As contemplated herein, when using the words or description “parameters104 a” or “cryptographic parameters 104 a” can specify a row ofparameters or values in a set of cryptographic parameters 104. In thismanner, a set of cryptographic parameters 104 a can refer to a specificrow identified by the column in “set A” with a collection of values inthe row to be used with key pair generation functions (such as with IDSone-time PM keys 103 e and/or PP one-time PM keys 101 e), ECDH keyexchange 215, ECC point addition operations for steps 213 and steps 223,key exchange steps 110 a and 110 b, symmetric ciphering algorithms 230,secure hash algorithms, and other cryptographic operations and steps ascontemplated herein. Set identifier 104 a can be an identity for a rowor set of values for cryptographic parameters 104. Key length 104 b canbe the length of keys in bits for PM keys used in system 100 and system200. ECC Curve name 104 c can be a name for an ECC curve used with PMkeys and key exchange algorithms in system 100, system 200, and othersystems herein.

Hash algorithm 104 d in cryptographic parameters 104 can be the name ofa secure hash algorithm, such as the exemplary SHA-256 algorithmdepicted, which may also be referred to as “SHA-2”. Hash algorithm 104 dcan also be used in a key derivation function (e.g. KDF 217 above inFIG. 2b and FIG. 2c ) and also with secure hash computation in formessage 207 b and step 208. Settings for a symmetric ciphering algorithm104 f can specify (i) the identity or name of a symmetric cipheringalgorithm 230 such as “AES”, “AES-SIV”, 3DES, Blowfish, (ii) the lengthof symmetric ciphering keys used with the symmetric ciphering algorithm230, (iii) a cipher chaining mode such as, but not limited to CBC, etc,and (iv) parameters for using a MAC code 233 and/or an initializationvector 232.

Random length 104 g can specify the length in bits for random numbers or“nonces” generated by both PP 101 and/or server 103 such as with randomnumber 208 b. A random number can comprise nonces to prevent replayattacks with the result that messages transmitted and received with therandom number can be unique. Other possibilities exist as well for datawithin cryptographic parameters 104, such as the specification of pointcompression, encoding rules such as distinguished encoding rules (DER),ASN or CSN syntax notation, padding rules, byte or bit orders such asbig endian, little endian, etc. In addition, a set of cryptographicparameters 104 could include an identity or name of a key derivationfunction for use with a KDF 217.

1. A method for a primary platform to securely receive a firmware, themethod comprising the primary platform (PP): recording a server staticpublic key and a PP private key; deriving a one-time PKI key paircomprising a PP one-time private key and a corresponding PP one-timepublic key, wherein the PP records the server static public key beforederiving the PP one-time public key; sending the PP one-time public keyand a random number; receiving (i) a secure hash value of the serverstatic public key and (ii) a server one-time public key; conducting anelliptic curve Diffie Hellman (ECDH) key exchange using the serverstatic public key, the server one-time public key, the PP private key,and the PP one-time private key in order to derive a symmetric cipheringkey; receiving a bound image comprising a ciphertext; decrypting theciphertext into the firmware and the random number, wherein the PPverifies that the decrypted random number equals the sent random number;loading the firmware into a memory; and operating an application usingthe firmware.
 2. The method of claim 1, further comprising conductingthe elliptic curve Diffie Hellman (ECDH) key exchange with an ellipticcurve point addition for the server static public key and the serverone-time public key.
 3. The method of claim 1, further comprisingconducting the elliptic curve Diffie Hellman (ECDH) key exchange with(i) a sum of the PP private key and the PP one-time private key and (ii)a modulus of the sum.
 4. The method of claim 1, wherein the PP (i) doesnot store a certificate for the server static public key and (ii) doesnot receive the certificate for the server static public key.
 5. Themethod of claim 1, wherein a tamper resistant element (TRE) in acomputing device operates the PP, and wherein the computing device usesan agent as a device driver to transfer the ciphertext from an imagedelivery server to the PP.
 6. The method of claim 1, further comprisingselecting the server static public key using the secure hash value ofthe server static public key:
 7. A method for a server to encrypt andtransfer a symmetric ciphering key, the method performed by the server,the method comprising: recording a server static private key, wherein adevice stores a corresponding server static public key; deriving aone-time PKI key pair comprising a server one-time private key and acorresponding server one-time public key, wherein the server records theserver static private key before deriving the server one-time publickey; receiving a device static public key and a device one-time publickey; conducting an elliptic curve point addition operation with thedevice static public key and the device one-time public key in order toderive a first point; calculating a modulus for a sum of the serverstatic private key and the server one-time private key; conducting anelliptic curve point multiplication operation with the first point andthe modulus in order to derive a second point; conducting a keyderivation function with the second point in order to derive anencryption key; encrypting the symmetric ciphering key with theencryption key; and sending the encrypted symmetric ciphering key to thedevice.
 8. The method of claim 7, wherein the server receives the devicestatic public key from a secure session before the server receives thedevice one-time public key from the device.
 9. The method of claim 7,further comprising recording, by the server, a set of cryptographicparameters for (i) the server static public key and the one-time PKI keypair and (ii) the key derivation function, wherein the cryptographicparameters specify at least a named elliptic curve and a secure hashalgorithm.
 10. The method of claim 7, further comprising deriving, bythe device, the encryption key using (i) a device one-time private keycorresponding to the device one-time public key, (ii) a device staticprivate key corresponding to the device static public key, (iii) aserver static public key corresponding to the server static private key,and (iv) the server one-time public key.
 11. The method of claim 7,wherein the device includes a tamper resistant element (TRE) and anagent, wherein the TRE reads the encrypted symmetric ciphering key usingthe agent, and wherein the TRE derives the encryption key and decryptsthe encrypted symmetric ciphering key using the encryption key.
 12. Themethod of claim 7, further comprising sending, by the server, aciphertext to the device, wherein the ciphertext is encrypted with thesymmetric ciphering key.
 13. The method of claim 7, further comprising:receiving, by the server, a random number from the device; andencrypting, by the server, the symmetric ciphering key and the randomnumber with the encryption key
 14. The method of claim 7, furthercomprising sending, by the server, a ciphertext to the device, whereinthe ciphertext is encrypted with the symmetric ciphering key.